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ABSTRACT 


This  thesis  analyzes  the  changes  within  the  Global  Transportation  Network 
(GTN)/In  Transit  Visibility  (ITV)  feeder  systems  and  the  subsequent  ITV  they  provide  by 
comparing  the  current  position  to  the  past  and  by  examining  future  trends.  Up  until  now, 
there  has  been  no  definitive  documentation  showing  the  initial  inception  or  the 
subsequent  improvements  that  have  taken  place  in  developing  the  GTN  and  feeder 
systems.  The  inception  of  the  GTN  is  documented,  including  some  of  the  “proof  of 
concept”  prototypes.  The  operational  prototypes  and  production  systems  are  also 
analyzed,  including  the  feeder  systems  used  in  the  GTN  and  how  the  GTN  performed 
during  operation  Desert  Shield/Storm.  USTRANSCOM’s  vision  of  the  future  GTN,  up 
to  FY04,  is  explained  along  with  the  authors’  view  of  possible  future  GTN  capabilities. 
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I. 


INTRODUCTION 


A.  PURPOSE 

This  research  shows  what  changes  have  occurred  within  Global  Transportation 
Network  (GTN)/In  Transit  Visibility  (ITV)  feeder  systems  and  the  subsequent  ITV  it 
provides  by  comparing  the  current  position  to  the  past  and  by  examining  future  trends. 
GTN  has  increased  in  capability  since  the  initial  concept  was  set  forth  in  1988.  To  date, 
there  is  no  single  document  or  research  to  show  the  advances  in  GTN/ITV  feeder  systems 
capability  and  the  subsequent  increased  ITV  of  cargo  and  passengers  in  the  system.  Data 
is  available  to  show  current  and  past  capability,  but  definitive  documentation  is  lacking  to 
show  the  initial  inception  or  the  subsequent  improvements  that  have  taken  place  in  the 
ongoing  development  of  GTN  and  feeder  systems.  In  addition,  current  capacity  is  not 
quantifiable  to  show  the  current  position  with  a  view  toward  desired  future  states. 

B.  RESEARCH  QUESTIONS 

1.  Primary  Research  Questions 

What  has  been  the  historical  ITV  capability  within  GTN  and  other  sources,  how 
have  the  capabilities  progressed  to  the  present  state,  and  what  are  the  desired  future 
capabilities  of  GTN/ITV,  given  advances  in  Information  Technology  (IT)? 

2.  Secondary  Research  Questions 

a.  What  were  the  lessons  learned  from  the  Persian  Gulf  War  in 
regards  to  Total  Asset  Visibility  (TAV)? 

b.  What  are  the  GTN  feeder  systems  and  associated  integration 
challenges? 
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c.  What  are  the  concerns  involved  with  future  development  of  the 
GTN? 

d.  What  technologies  need  to  be  developed  or  improved  for  increased 
exploitation  of  GTN  capabilities? 

C.  RESEARCH  SCOPE  AND  METHODOLOGY 

This  research  will  analyze  past  (pre-GTN)  capability,  current  capability,  and 
future  desired  capabilities  of  the  GTN.  The  following  resources  were  used  to  accomplish 
this  analysis: 

1.  Literature  search  of  books,  magazine  articles,  CD-ROM  systems,  and 
other  library  information. 

2.  Conduct  personal  interviews. 

3.  Conduct  research  on  Internet  web-sites. 

4.  Complete  data  gathering  and  interviews  at  USTRANSCOM. 

5.  Electronic  messaging  (email). 

D.  ORGANIZATION  OF  STUDY 

Chapter  II  will  describe  the  inception  of  GTN  and  introduce  some  of  the  early 
“proof-of-concept”  prototypes.  The  background  will  also  include  definitions  and 
descriptions  of  TAV,  ITV,  and  Electronic  Data  Interchange  (EDI)  that  all  play  a  role  in 
the  GTN,  Chapter  HI  describes  GTN  evolution  and  examines  the  various  operational 
prototypes  and  production  systems.  The  development  of  GTN  capabilities  and 
performance  through  time  is  illustrated  by  examining  the  changing  user  requirements, 
lessons  learned  from  the  Persian  Gulf  War  and  other  contingencies,  as  well  as  changes  in 
information  technology.  The  chapter  also  describes  the  current  GTN  feeder  systems. 

This  includes  the  history  of  integration  and  the  associated  challenges  with  integration  of 
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feeder  systems.  To  aid  in  the  analysis,  migration  and  legacy  systems  are  defined  and 
discussed. 

In  Chapter  IV,  USTRANSCOM’s  vision  of  future  desired  GTN  capabilities  are 
presented.  In  envisioning  the  future  capabilities  of  the  GTN,  the  authors  took  into 
account  USTRANSCOM’s  vision,  lessons  learned  from  the  research,  and  future  trends  of 
IT.  Using  this  information,  the  authors  presented  an  operational  concept  of  the  GTN  that 
would  address  present  and  future  DOD  and  commercial  transportation  challenges. 

Chapter  V  summarizes  the  findings  of  the  research  and  presents  recommendations 
for  further  research  and  study.  The  summary  includes  recommendations  for  business 
processes,  infrastructure,  and  management  practices  that  will  facilitate  reaching  the 
envisioned  GTN  goals. 

E.  BENEFITS  OF  STUDY 

The  results  of  this  research  will  show  what  changes  have  occurred  within  Global 
Transportation  Network  (GTN)/In  Transit  Visibility  (ITV)  feeder  systems  and  the 
subsequent  ITV  provided.  It  will  also  provide  a  concept  of  future  GTN  capabilities  that 
may  prove  beneficial  to  the  Defense  Transportation  System  (DTS).  The  goal  of  this 
study  is  to  provide  leadership  in  the  Joint  arena,  a  basis  of  justification  for  business 
processes,  management,  and  infrastructure  changes  necessary  to  reach  desired  future 
GTN  capabilities  that  will  evolve  over  time. 
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H.  BACKGROUND 


A.  INTRODUCTION 

USTRANSCOM  was  established  in  1987  as  the  Department  of  Defense’s 
manager  for  common  user  lift  during  wartime.  In  1992,  a  Secretary  of  Defense 
memorandum  designated  the  Commander  in  Chief,  USTRANSCOM  as  the  single 
manager  for  defense  transportation  during  both  peace  and  wartime.  This  memorandum 
was  superceded  by  DOD  directive  5158.4  on  8  January  1993,  which  transferred 
combatant  command  of  Air  Mobility  Command  (AMC),  Military  Sealift  Command 
(MSC),  and  Military  Traffic  Management  Command  (MTMC)  to  USCINCTRANS.  All 
military  transportation  assets,  except  service-unique  assets  were  also  transferred  to 
USCINCTRANS.  USTRANSCOM  coordinates  personnel  and  material  movement  via 
both  military  and  commercial  modes  of  transportation,  as  well  as  providing  control  and 
supervision  of  all  transportation  services.  [Ref.  1] 

Shortly  after  creating  USTRANSCOM,  the  GTN  concept  was  established  as  the 
backbone  of  the  DTS  information  network  and  was  considered  one  of  USTRANSCOM’ s 
highest  priorities.  To  understand  the  GTN  concept  and  subsequent  developments,  an 
understanding  of  TAV,  ITV,  and  EDI  is  necessary. 

B.  TOTAL  ASSET  VISIBILITY  (TAV) 

To  understand  how  TAV  is  integrated  into  the  GTN,  TAV  must  be  defined.  TAV 
is  defined  as: 

The  ability  to  gather  information  from  DOD  systems  on  the  identification, 
quantity,  condition,  location,  movement,  and  status  of  material,  units,  personnel, 
equipment,  and  supplies  anywhere  in  the  logistics  system  at  any  time,  and  to 
apply  information  to  improve  logistics  processes.  DOD  has  expanded  TAV  to 
include  all  classes  of  supply,  units,  personnel,  and  medical  patients.  TAV 
provides  an  essential  management  tool  to  customers,  item  managers,  weapon 
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system  managers,  and  commanders  in  chief  (CINCS)  to  move  and  redirect 
materiel,  to  redistribute  items,  to  view  forces  flowing  into  theaters,  and  to 
optimize  overseas  stock  positioning.  [Ref.  2] 

TAV  includes  assets  that  are  in  storage,  in  process,  and  in  transit.  In  storage  assets 
are  defined  as: 

All  material  being  stored  at  retail  consumer  sites  (operating  activity  storerooms  or 
warehouses);  retail  intermediate  storage  sites,  contractor  facilities  (as 
government-furnished  material),  disposal  activities,  or  wholesale  depots. 

[Ref.  3:pp.  2-9] 

In  process  assets  are  defined  as: 

All  material  that  are  either  on  order  from  DOD  vendors  but  not  yet  shipped, 
undergoing  repair  at  depot-level  organic  or  commercial  maintenance  facilities,  or 
at  intermediate  maintenance  facilities.  [Ref.  3:pp.  2-9] 

In  transit  assets  are  defined  as: 

All  personnel  and  materiel  that  are  being  shipped  from  external  procurement  or 
repair  sources,  or  moving  within  the  DOD  distribution  system.  [Ref.  3:pp.  2-9] 


TAV  usually  involves  Automatic  Identification  Technology  (AIT).  AIT 
facilitates  data  collection  and  transmission  to  Automated  Information  Systems  (AIS). 

AIT  encompasses  a  variety  of  read  and  write  data  storage  technologies  that  capture  asset 
identification  information.  Those  technologies  include  bar  codes,  magnetic  stripes, 
integrated  circuit  cards,  optical  memory  cards,  and  radio  frequency  identification  tags. 
ATT  also  includes  the  hardware  and  software  used  to  store  information  in  storage  devices, 
read  the  information  stored  on  them,  and  integrate  that  information  with  other  logistics 
data.  It  also  uses  satellites  to  track  and  redirect  shipments.  [Ref.  4:pp.  iii-iv] 


6 


C.  INTRANSIT  VISIBILITY  (ITV) 


IT V  is  an  integral  component  of  TAV.  ITV  is  the  ability  to  track  the  identity, 
status,  and  location  of  DOD  unit  and  non-unit  cargo,  passengers,  patients,  and  personal 
property  from  origin  to  consignee  or  destination  during  peace,  contingencies,  and  war. 
using  AIT,  ITV  provides  “real-time”  visibility  and  information  flow  that  can  prove  vital 
to  operation  and  support  commanders.  Knowing  exactly  where  assets  are  located  reduces 
the  uncertainty  of  asset  management,  and  in  turn  reduces  unnecessary  inventory.  When 
rrv  is  not  in  place,  redundant  inventory  acts  as  a  “back-up”  to  the  system  providing 
operational  commanders  confidence  in  the  logistics  support  provided  to  them.  These 
redundancies,  however,  increase  the  cost  of  material  in  the  logistics  pipeline  and  also 
increase  inventory  and  warehousing  costs.  Numerous  military  operations  have  confirmed 
that  a  comprehensive  ITV  program  is  key  to  ensuring  responsiveness,  ensuring  needed 
assets  are  diverted  to  higher  priority  destinations,  and  that  shipments  can  be  reconstituted 
to  fulfill  the  needs  of  operational  commanders.  [Ref.  3:p.  iii] 

D.  ELECTRONIC  DATA  INTERCHANGE 

Over  the  years,  paper  has  been  the  traditional  medium  for  documenting  business 
transactions.  Company  records  are  filed  on  paper,  which  needs  to  be  physically  carried 
between  companies  to  exchange  information.  Computers  allowed  companies  to  process 
data  electronically,  but  paper  still  needed  to  be  physically  moved  between  companies. 
The  common  practice  has  been  for  a  company  to  enter  data  into  a  business  application, 
print  the  data  on  paper,  and  mail  it  to  a  trading  partner.  The  trading  partner,  after 
receiving  the  paper,  re-keys  the  data  into  another  business  application.  This  system  of 
data  exchange  relies  on  the  timeliness  of  the  delivery  system  and  is  susceptible  to  errors 
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during  data  input.  Although  the  computer  allowed  data  to  be  processed  and  stored 
electronically,  an  efficient  way  to  communicate  that  data  was  needed.  [Ref.  5] 

Communicating  data  electronically  was  realized  with  the  widespread  use  of 
computer  telecommunications.  Transmitting  data  over  telephone  lines  provided  a  means 
of  data  exchange  without  the  delay  of  delivery  systems,  with  less  paperwork  and  fewer 
errors  in  transcribing  data.  [Ref.  5] 

Computer  telecommunications  solved  only  part  of  the  problem.  To  transfer  data 
via  computer  telecommunications,  a  data  exchange  format  had  to  be  agreed  upon  prior  to 
transferring  data.  This  made  it  very  difficult  for  data  to  be  transferred  between  many 
trading  partners.  [Ref.  5] 

In  the  late  1970’s,  work  began  on  national  and  international  Electronic  Data 
Interchange  (EDI)  standards.  To  make  EDI  work  for  all  users,  a  set  of  standard  data 
formats  needed  to  be  created  that: 

•  were  hardware  independent; 

•  were  unambiguous,  such  that  they  could  be  used  by  all  trading  partners; 

•  reduced  the  labor-intensive  tasks  of  exchanging  data  (e.g.,  data  re-entry);  and 

•  allowed  the  data  transmitter  to  control  the  exchange,  including  knowing  if  and 
when  the  recipient  received  the  transaction. 

Although  today  there  is  much  syntax  for  EDI,  only  two  are  widely  recognized: 
X.12  and  the  Electronic  Data  Interchange  for  Administration,  Commerce,  and  Transport 
(EDIFACT).  These  two  families  of  standards  are  mandated  for  use  within  the  Federal 
Government.  [Ref.  5] 
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Uses  of  EDI  include  but  are  not  limited  to  the  following:  generating  purchasing 
orders,  sending  invoices  and  bills  of  lading,  advance  shipment  notification,  and  shipment 
tracking.  [Ref.  6]  By  1993,  the  federal  government  began  implementing  EDI  with  an 
executive  order  directing  full-scale  implementation  of  the  federal  electronic  commerce 
system  by  1997.  Procurement  reform  legislation  was  also  passed  that  provided 
incentives  for  government  agencies  to  use  EDI  by  raising  the  small-purchase  threshold 
from  $25,000  to  $100,000  for  EDI-based  procurement  transactions.  [Ref.  7]  The  federal 
government  has  since  adopted  ANSI  X.12  formatting  standards  to  conduct  business  using 
EDI.  DOD  uses  Standard  Exchange  Format  (SEF)  which  is  based  on  the  ANSI  X.12  and 
EDIFACT  formats;  this  allows  DOD  to  conduct  business  with  commercial  industry.  [Ref. 
8] 

DOD’s  EDI  implementation  is  uses  the  Defense  Transportation  Electronic  Data 
Interchange  Program  (DTEDI).  When  fully  implemented,  DTEDI  will  replace  many  of 
the  routine  freight  and  personal  property  documents  with  EDI  transactions.  Figure  1 
shows  the  operating  concept  of  DTEDI.  [Ref.  8] 

EDI  fully  exploits  electronic  commerce  in  the  DOD.  Taking  the  lead  from  the 
commercial  sector,  DOD  has  been  a  pioneer  in  developing  new  uses  of  electronic 
commerce.  DOD  is  making  strong  progress  in  moving  towards  a  paperless  environment, 
using  EDI  and  electronic  commerce  in  the  areas  of  contract  administration  and  finance, 
internet-based  commerce,  paper-free  weapons  systems  support,  internet-based  publishing, 
consolidating  logistics  and  transportation,  travel  reengineering,  and  household  goods 
transportation.  [Ref.  9] 
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Figure  1.  DTEDI  Program  Operating  Concept  [Ref.  3:  p.  1-6] 


E.  SYSTEM  INCEPTION 
1.  Overview 

In  the  past,  single  managers  for  air,  sea,  and  land  transportation  within  each  of  the 
services  managed  transportation  for  their  service.  This  was  accomplished  through  the 
USTRANSCOM  Transportation  Component  Commands  (TCCs);  the  Army’s  Military 
Traffic  Management  Command  (MTMC),  the  Navy’s  Military  Sealift  Command  (MSC), 
and  the  Air  Force’s  Air  Mobility  Command  (AMC).  [Ref.  10:p.  10] 

Along  with  the  emphasis  on  joint  operations  came  the  need  to  project  power  to 
any  location  in  the  world.  In  an  environment  of  reduced  military  resources,  the  need  for  a 


highly  effective  and  efficient  DOD  transportation  capability  became  increasingly  evident. 
Each  service  and  defense  agency  had  its  own  existing  automated  system  for 
transportation  management  that  was  partially  integrated  and  supported  by  policies  and 
procedures  unique  to  each  service.  The  shortfall  of  this  arrangement  was  that  there  was 
virtually  no  horizontal  integration  or  coordinating  policies  and  procedures  or  data 
management  activities  between  the  services  and  defense  agencies.  The  result  was  a  very 
complex  and  confusing  array  of  systems  that  individually  provided  the  needed 
transportation  support  to  the  services  but  failed  to  provide  the  information  necessary  for 
centrally  managing  the  joint  transportation  network.  [Ref.  10:p.  10] 

Figure  2  illustrates  the  various  integration  disconnects  that  existed  between  the 
independent  systems.  A  vertical  disconnect  existed  between  joint/specified  systems  used 
to  plan  movements  and  the  service/component  systems  that  received  movement 
requirements  and  executed  movements.  Both  systems  had  related  capabilities  but  did  not 
exchange  transportation-related  data.  Horizontal  disconnects  also  existed  between  the 
individual  service/component  systems  that  were  responsible  for  DOD  transportation. 
Policies  and  procedures  existed  for  the  DTS;  however,  they  did  not  coordinate  or 
integrate  the  air  and  surface  systems.  Effective  command  and  control  (C2)  requires  that 
variations  in  actual  and  planned  movement  requirements  are  monitored  and  managed  to 
control  transportation  assets.  Vertical  and  horizontal  disconnects  inhibit  free  information 
flows  and  hide  critical  C2  information.  [Ref.  10:pp.  10-11] 
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Figure  2.  System  Disconnects  [Ref.  10:p.  11] 


F.  HISTORY 

Shortly  after  the  birth  of  USTRANSCOM,  a  Concept  of  Operations  (CONOPS)  was 
completed  in  1987.  The  next  challenge  to  USTRANSCOM  was  to  develop  an 
Automated  Data  Processing  (ADP)  master  plan ,  which  fell  under  the  responsibility  of  the 
Directorate  for  Command,  Control,  Communications,  and  Computer  Systems  (CDS). 

The  goal  was  to  develop  an  ADP  system  with  the  capability  to  integrate  mobility, 
deployment,  and  acquisition  of  transportation  ADP  systems  to  ensure  overall  system 
compatibility.  This  system  also  had  to  be  integrated  into  transportation  C2  systems.  [Ref. 
ll:p.  46] 
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The  complexity  of  integrating  the  existing  transportation  ADP  systems  was 
enormous.  For  example,  a  single  portion  of  the  project,  MTMC’s  automated  system  for 
transportation,  involved  six  major  systems,  which  included  43  subsystems  and  2,400 
application  programs.  When  completed,  the  ADP  master  plan  would  set  the  groundwork 
for  USTRANSCOM’s  success.  [Ref.  ll:p.  46] 

In  January  1988,  the  Director  of  USTRANSCOM’s  Directorate  for  CDS, 
Brigadier  General  Beasley,  changed  the  name  of  USTRANSCOM’s  ADP  master  plan. 

To  more  accurately  define  its  scope  and  purpose,  it  would  henceforth  be  referred  to  as  the 
CDS  Master  Plan.  Brigadier  General  Beasley  also  organized  the  CDS  Master  Plan 
development  into  four  stages.  [Ref.  12:p.  141] 

The  first  stage  established  a  baseline  of  current  systems.  The  second  stage 
defined  the  Joint  Deployment  Community  systems  requirements.  The  third  stage 
compared  the  requirements  to  the  baseline  and  assessed  the  deficiencies.  The  fourth 
stage  produced  a  set  of  technical  solutions  based  on  the  list  of  deficiencies.  These 
solutions  were  divided  into  three  major  areas  for  developing  integrated  systems.  The 
three  areas  were  planning,  command  and  control,  and  intransit  visibility.  [Ref.  12:p.  141] 
These  three  areas  would  ultimately  develop  into  the  Global  Transportation 
Network  (GTN),  an  integrated  system  of  command,  control,  communications,  and 
computer  systems.  This  network  would  be  supported  by  procedures,  policies,  and 
personnel  employed  and  managed  by  USTRANSCOM  to  meet  its  global  transportation 
mission. 

By  the  end  of  1988,  although  still  early  in  a  conceptual  stage,  the  GTN  appeared 
to  be  a  viable,  long-term  solution  to  the  current  Joint  Deployment  Community’s  CDS 
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problems.  It  was  thought  that  being  able  to  interface  with  sophisticated  government  and 
civilian  CD  systems,  the  GTN  would  provide  in-transit  visibility  and  improve 
USTRANSCOM’s  ability  to  anticipate  user  requirements.  To  harness  the  optimum 
benefit  for  transportation  management,  the  GTN  had  to  provide  security  for  both 
commercial  and  government  vendors,  standardize  data,  and  capture  the  best  of 
commercial  information  technology.  It  would  also  have  to  allow  for  rapid  prototyping 
and  provide  the  DOD  with  substantial  savings  in  transportation  costs.  [Ref.  12:p.  145] 

By  the  end  of  1988,  a  Memorandum  of  Understanding  (MOU)  was  also  drafted  to 
gain  the  support  of  the  Air  Force  Systems  Command  (AFSC)  to  develop  the  GTN.  The 
proposed  MOU  outlined  the  responsibilities  of  AFSC  and  USTRANSCOM.  AFSC’s 
responsibilities  were  outlined  as  follows: 

•  Serve  as  program  manager  for  technical  studies  and  systems  development 
support 

•  Provide  program  planning  to  assess  ongoing  and  planned  activities 

•  Develop  alternative  solutions  and  courses  of  action 

•  Advise  on  the  development  and  implementation  of  appropriate  acquisition 
strategies 

•  Assist  in  working  with  other  Commanders  in  Chief,  services,  and  agencies  in 
planning  and  developing  integrated,  interoperable,  compatible,  and  mutually 

supporting  transportation  C4S 

USTRANSCOM’s  responsibilities  were  outlined  in  the  MOU  as  follows: 

•  Provide  requirements  direction  and  guidance  for  analyzing  and  developing  the 
C4S  in  support  of  the  command’s  mission 
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•  Review,  evaluate,  and  validate  AFSC-developed  plans  and  assessments 

•  Identify  special  studies  and  analyses  needed  to  assure  proper  integration  and 
interoperability  of  the  command’ s  C4S . 

“The  two  commands  would  work  together  to  man  and  fund  the  activities  listed  in  the 
MOU.”  AFSC’s  Commander,  Gen  Bernard  P.  Randolph,  signed  the  MOU  in  January 
1989.  [Ref.  12:p.  147] 

On  16  March  1989,  a  five-year  labor  hour  contract  was  awarded  to  Computer 
Sciences  Corporation  (CSC)  to  support  USTRANSCOM  in  developing  the  CDS  master 
plan.  The  master  plan  highlighted  USTRANSCOM’ s  mission,  organizational 
relationships  and  CDS  baseline.  It  also  outlined  the  requirements  and  deficiencies 
identified  from  the  baseline  and  some  solutions  to  those  deficiencies.  In  essence,  the 
document  outlined  a  plan  to  transform  the  existing  multiple  independent  systems  to  an 
integrated  CD  system.  [Ref.  13:p.  158-159] 

In  October  1988,  the  Secretary  of  Defense  directed  MTMC  to  consider  the 
feasibility  of  developing  a  worldwide  ITV  prototype  for  DOD.  In  December  1988,  the 
JCS  tasked  USTRANSCOM  to  produce  a  proposal  for  a  pilot  ITV  program.  As  a  result, 
USTRANSCOM  and  MTMC  began  to  coordinate  their  efforts  to  ensure  their  work  would 
be  compatible  with  the  GTN.  Early  in  1989,  USTRANSCOM  began  to  plan  a  proof-of- 
concept  prototype  and  selected  the  best  databases  to  use  in  the  project.  These  databases 
were: 

•  MTMC’s  Terminal  Management  System  (Honeywell  DPS-8),  hosted  in 
Oakland,  California 

•  Military  Airlift  Command’s  Passenger  Reservation  and  Manifesting  System 
(PRAMS)(Honeywell  DPS-8),  Scott  Air  Force  Base,  Illinois 
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•  The  Army’s  Logistics  Control  Activity  Databases  (IBM),  San  Francisco, 
California 

•  DOD’s  Defense  Transportation  Tracking  System  (AT&T  3B2),  Norfolk, 
Virginia 

To  demonstrate  the  capability  to  tap  into  civilian  systems,  American  President 
Lines’  Tracking  System  (Eagle  Link)  (IBM  3090),  San  Mateo,  California  was  also 
included  as  one  of  the  information  databases.  [Ref.  13:pp.  161-162] 

Since  both  the  USTRANSCOM  and  MTMC  prototypes  involved  very  similar 
technologies,  General  Cassidy,  Commander  in  Chief,  USTRANSCOM,  decided  to 
combine  them  and  use  the  best  features  of  each  prototype.  A  UNIX-based  “surround” 
technology  developed  by  Cambridge  Technology  Group  (CTG)  was  chosen  as  the  likely 
approach  for  the  GTN/TTV  prototype.  USTRANSCOM  contracted  with  CTG  to  develop 
two  GTN/ITV  proof-of-concept  prototypes  and  provide  the  hardware  and  software.  The 
$200,000  contract  also  included  a  one-year  lease  for  an  NCR  Tower  computer,  training, 
documentation,  and  a  demonstration  at  Scott  Air  Force  Base.  [Ref.  13:p.  162] 

In  August  1989,  the  GTN/ITV  prototype  was  installed  at  USTRANSCOM  and 
successfully  demonstrated.  Throughout  the  rest  of  1989,  prototype  demonstrations  were 
held  at  US  Pacific  Command  (USPACOM)  headquarters  and  at  US  European  Command 
(USEUCOM)  headquarters.  The  prototypes  focused  on  tracking  unit  and  non-unit  cargo 
and  personnel  across  the  Pacific,  and  ammunition  and  container  tracking  to  Europe.  The 
tracking  was  accomplished  by  answering  a  small  number  of  ITV  inquiries  that  pulled 
“real  time”  ITV  information  from  existing  databases.  These  successful  demonstrations 
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prompted  further  development  and  investment  toward  expanded  capabilities  and 
prototypes  for  the  worldwide  GTN/ITV  system.  [Ref.  13:  p.  163] 

G.  CHAPTER  SUMMARY 

USTRANSCOM  was  established  as  the  single  manager  for  transportation  in  both 
peace  and  war  through  its  Transportation  Component  Commands  (TCCs).  As  part  of  its 
mission,  USTRANSCOM  was  tasked  with  exploring  the  feasibility  of  creating  a 
transportation  management  system  that  would  provide  ITV  to  all  DOD  transportation 
users  throughout  the  world.  The  system,  known  as  the  Global  Transportation  Network 
(GTN)  used  existing  databases  as  the  source  data  to  provide  much  needed  real-time 
information  to  support  and  operational  commanders. 

One  of  the  major  challenges  to  building  such  a  system  was  the  integration  of 
existing  independent  automated  information  systems  that  provide  critical  transportation 
data  to  their  unique  service  component  but  do  not  communicate  effectively  with  other 
transportation  systems. 

Shortly  after  creating  the  GTN  concept,  the  feasibility  of  providing  global  ITV 
was  demonstrated  through  “proof-of-concept”  prototypes.  These  prototypes  were 
deemed  a  success,  prompting  the  first  operational  prototypes,  which  will  be  discussed  in 
the  next  chapter. 
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in.  THE  GLOBAL  TRANSPORTATION  NETWORK 


A.  INTRODUCTION 

The  “proof-of-concept”  prototypes  were  successfully  demonstrated  and  by  the 
end  of  1989,  USTRANSCOM  defined  objectives  for  the  operational  prototype.  Those 
objectives  are  listed  in  table  1.  In  addition  to  defining  objectives  for  the  GTN,  some 
challenges  were  recognized.  System  security,  data  standardization,  and  managing 
external  databases  were  causes  for  concern.  At  the  end  of  1989,  project  costs  remained 
unknown  and  funding  sources  were  undetermined.  [Ref.  13:p.  164] 

USTRANSCOM  planned  to  develop  the  GTN  incrementally,  periodically 
releasing  versions  containing  a  few  major  integration  changes  and  appropriate  technical 
infrastructure.  As  the  system  grew,  so  would  USTRANSCOM’ s  responsibility  for 
maintenance,  network  management,  security,  and  transportation  information  integration 
and  administration.  [Ref.  13:p.  164] 

UNITED  STATES  TRANSPORTATION  COMMAND  GLOBAL 
TRANSPORTATION  NETWORK/INTRANSIT  VISIBILITY 
OPERATION  PROTOTYPE  OBJECTIVES 


I.  Refine  functional  requirements  for  the  Command,  Control, 
Communications,  and  Computer  Systems  Master  Plan. 

II.  Quickly  and  economically  develop  a  Global  Transportation 
Network  technical  capability  that  addresses  all  three  Global 
Transportation  Network  elements:  Command  and  Control, 
Planning  (Joint  Operation  Planning  and  Execution  System),  and 
Intransit  Visibility. 
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m.  Satisfy  the  Deputy  Secretary  of  Defense’s  requirement  for  Military 
Traffic  Management  Command  to  develop  an  Intransit  Visibility 
prototype. 

IV .  Define  technical  specifications  for  the  Global  Transportation 
Network  program. 

V .  Produce  a  viable,  usable,  fielded  information  prototype  in  three 
theaters  and  the  United  States  Transportation  Command. 

(1)  Prove  a  capability  to  provide  immediate  visibility  of 
transportation  assets,  personnel,  and  cargo  movements. 

(2)  Prove  a  capability  to  provide  command  and  control  of 
global  mobility  operations  and  determine  information 
critical  to  the  success  of  a  supported  commander’s 
operation. 

(3)  Prove  a  capability  to  provide  information  expansion  for 
quick  response  planning  and  replanning 

(4)  Develop  effective  technologies  to  integrate  Department  of 
Defense  and  civil  sector  transportation  information 
systems. 

(5)  Isolate  the  user  from  the  diverse  technical  requirements  of 
multiple  information  systems,  yet  allow  free  access  to 
strategic  decision  information. 

(6)  Develop  usable  methodologies  to  present  strategic 
transportation  decision  information. 

Table  1.  [Ref.  13:p.  164] 

B.  DATA  STANDARDIZATION 

Lack  of  standardized  data  was  also  considered  to  be  a  major  impediment  to 
implementing  the  GTN.  Different  systems  represented  the  same  information  in  a  variety 
of  different  formats  and  definitions.  It  was  difficult  for  different  systems  to  share 
information  when,  for  example,  Rhein-Main  Air  Base,  Germany  was  represented  as 
“GYRZ”,  “EDAF,”  or  “FRF’  depending  on  the  system  used.  [Ref.  13:p.  166] 
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To  resolve  the  standardization  problem,  the  Deputy  Secretary  of  Defense 
mandated  that  unnecessary  redundancy  be  reduced  by  developing  common  data 
requirements  and  formats.  To  accomplish  this  task,  an  executive  level  body  was  formed 
with  representation  from  within  and  outside  DOD.  In  particular,  this  executive  body  was 
tasked  to: 

•  Use  a  Corporate  Information  Management  program  developed  for  DOD  to 
recommend  an  overall  approach  and  plan  of  action  to  increase  the  availability 
of  standardized  information  in  common  areas. 

•  Recommend  corrective  actions  to  the  process  and  procedures  used  for 
overseeing  new  DOD  information  systems  and  software  development. 

•  Establish  working  groups,  in  both  technical  and  common  business  areas,  to 
develop  information  requirements  and  data  formats  in  DOD  that  are  uniform 
and  consistent.  [Ref.  13:p.  167] 

In  1990,  working  with  its  component  commands,  USTRANSCOM  drafted  a 
regulation  entitled  “Data  Management  and  Standards  Program.”  The  Data  Management 
and  Standards  Program  set  the  foundation  for  data  sharing  between  the  commands  and 
defined  the  requirement  for  a  Defense  Transportation  Data  Dictionary.  [Ref.  14:p.  97] 

C.  GTN  PROTOTYPE  DEVELOPMENT 

During  1990,  USTRANSCOM  made  several  management  changes  as  well  as 
significant  progress  toward  fielding  a  GTN  operational  prototype.  Some  of  the  major 
management  changes  included  revising  the  GTN  Memorandum  of  Agreement  (MO A) 
with  MTMC.  Under  the  new  agreement,  USTRANSCOM’s  Directorate  of  Operations 

and  Logistics  (TCJ3/4)  became  the  GTN  Program  Manager  and  the  Directorate  of  C4S 
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(TCJ6)  became  the  Deputy  Program  Manager  for  technical  direction,  acquisition  strategy, 
network  management,  system  development,  and  integration.  MTMC  became  the  Deputy 
Program  Manager  for  the  GTN/TTV  prototype.  [Ref.  14:p.  98] 

Under  the  new  GTN  management  structure,  the  development  of  the  GTN  made 
sigmficant  progress.  In  March,  the  proof  of  concept  prototype  was  evaluated  during 
Operation  Team  Spirit.  It  was  also  demonstrated  at  the  Pentagon  to  senior  government 
officials.  Following  the  demonstration,  USTRANSCOM  performed  an  extensive  review 

f 

of  CINC  and  other  DOD  agency  ITV  needs,  and  on  20  March  1990,  released  a  request  for 
proposal  for  a  GTN  Operational  Prototype  Version  1.  The  contract  was  awarded  to 
Advanced  Technology  Incorporated  teamed  with  TRW  on  19  April.  The  plan  was  to  field 
the  prototype  at  25  locations  in  September,  but  Operation  Desert  Shield  altered  the 
schedule  and  the  prototype  was  limited  to  MTMC,  Military  Airlift  Command  (AMC), 
United  States  Central  Command,  and  USTRANSCOM.  [Ref.  14:pp.  98-99] 

D.  OPERATION  DESERT  SHIELD/STORM 

The  lack  of  information  concerning  movement  and  identification  of  shipments 
and  units  entering  a  theater  of  war  has  always  been  a  major  concern  for  operational 
commanders.  Inadequate  ITV  was  particularly  apparent  during  Operation  Desert 
Shield/Storm.  During  Desert  Shield/Storm,  more  than  40,000  containers  entered  the 
theater  of  operations.  Over  half  of  the  containers  had  to  be  opened,  inventoried,  resealed, 
and  put  back  into  the  transportation  system  simply  because  military  personnel  in  theatre 
did  not  know  what  they  contained.  In  addition  to  container  identification  problems,  lack 
of  patient  movement  information  caused  60  percent  of  evacuated  patients  to  end  up  at  the 
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wrong  destination.  These  visibility  shortfalls  also  cost  DOD  an  estimated  $150  million  in 
unnecessary  demurrage  and  detention  fees  for  containers.  [Ref.  15:p.  1-1] 

UV  capability  was  essentially  non-existent  during  Operation  Desert  Storm/Shield 
for  several  inter-related  reasons.  Dozens  of  transportation  systems  lacked  interfaces  and 
data  standardization.  The  lack  of  common  software  language  and  hardware  connectivity 
did  not  allow  various  service  systems  to  effectively  communicate  with  each  other. 

Recognizing  the  ITV  shortfall,  USTRANSCOM  and  its  component  commands 
developed  a  very  limited  ITV  capability  during  Desert  Shield/Storm.  USTRANSCOM 
and  MAC  developed  interfaces  between  the  Joint  Operational  Planning  and  Execution 
System  (JOPES)  and  MAC’S  Global  Decision  Support  System  (GDSS).  The  result  of 
this  interface  was  that  JOPES  provided  actual  carrier  movement  schedules  with  real 
manifests  attached  for  movement  tracking.  USTRANSCOM  directed  MAC  teams  to 
report  what  was  loaded  on  departing  aircraft  via  the  GDSS  and  the  Automatic  Digital 
Network  (AUTODIN).  MAC  moved  Remote  Consolidated  Aerial  Port  Subsystems 
(RCAPS)  terminals  to  aerial  ports  in  the  United  States  and  the  Area  of  Operations 
(AOR).  A  deployable,  more  flexible  version  of  CAPS,  RCAPS  provided  users  access  to 
cargo  and  passenger  manifest  information  using  personal  computers  and  local  area 
networks  tied  to  CAPS  long-haul  lines  and  the  Defense  Data  Network  (DDN).  [Ref.  16:p. 
28] 

Upon  completing  the  Gulf  War,  USTRANSCOM  concentrated  its  efforts  on 
planning  and  executing  the  redeployment  of  US  forces,  supplies,  and  equipment  from  the 
USCENTCOM  AOR.  The  redeployment,  nicknamed  “Desert  Sortie,”  began  on  1 1 
March  1991  and  was  completed  on  27  September  1991.  As  the  effort  shifted  from  Desert 
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Storm  to  Desert  Sortie  operations,  the  requirement  for  information  on  the  redeployment 
created  the  need  for  upgrading  critical  communications  and  computer  systems.  These 
systems  included  MAC’S  primary  command  and  control  system,  GDSS,  the  Joint  Staffs 
JOPES,  and  USTRANSCOM’s  GTN,  which  included  interfaces  with  the  GDSS  to 
provide  intransit  visibility.  USTRANSCOM  and  MAC  also  used  the  RCAPS  mentioned 
above  to  provide  visibility  to  returning  troops’  home  stations. 

[Ref.  17:pp.  42, 51] 

During  Desert  Sortie,  USTRANSCOM  realized  there  was  a  disconnect  between 
the  Defense  Medical  Regulating  Information  System  and  the  Automated  Patient 
Evacuation  System.  Although  the  systems  interfaced,  neither  system  had  the  capacity  to 
function  in  a  major  contingency  and  maintain  intransit  patient  visibility.  To  deal  with 
this  shortfall,  USTRANSCOM  hosted  the  Joint  Casualty  Evacuation  Working  Group  to 
review  lessons  learned  from  Operation  Desert  Shield/Storm.  The  goals  of  the  conference 
were  to  isolate  common  joint  problems,  assign  tasks  to  work  issues,  pursue  consensus  to 
consolidate  intertheater  medical  regulating,  and  establish  two  working  groups  to  work  on 
issues  concerning  joint  evacuation,  data  system  standardization  and  interface  between 
different  theatres. 

Three  recommendations  came  out  of  the  conference:  establish  a  single  joint 
integrated  data  system  for  medical  regulating  worldwide;  USTRANSCOM,  along  with 
the  services  and  other  organizations,  to  provide  a  proposal  to  the  JCS  to  allow 
USTRANSCOM  to  assume  an  effective  level  of  command  and  control  of  worldwide 
medical  regulating;  and  the  Joint  Staff  s  Logistics  Medical  Readiness  Division  was 
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tasked  with  writing  and  staffing  a  joint  doctrine  paper  addressing  joint  casualty 
evacuation  issues.  [Ref.  17:pp.  42] 

USTRANSCOM  had  the  responsibility  of  producing  the  GTN,  but  the  lessons 
learned  from  Desert  Shield/Storm/Sortie  made  it  apparent  that  if  the  GTN  was  to  meet  the 
warfighter  needs  and  expectations,  USTRANSCOM  would  have  to  be  given  peacetime 
authority  to  enforce  system  compatibility,  data  standardization,  training,  and 
documentation.  Subsequently,  on  14  February  1992,  a  Secretary  of  Defense 
memorandum  designated  the  Commander  in  Chief,  USTRANSCOM  as  the  single 
manager  for  defense  transportation.  This  designation  assigned  the  three  Transportation 
Component  Commands  (TCCs)  to  USTRANSCOM  during  peace  in  addition  to  wartime. 
As  the  sole  manager  for  defense  transportation,  USTRANSCOM  now  had  the  authority 
to  accomplish  the  goals  of  a  single,  joint,  integrated  GTN.  [Ref.  16:pp.  28-29] 

E.  POST  GULF  WAR  GTN  PROTOTYPE  DEVELOPMENT 

GTN  Version  1.0  was  highly  information-intensive  because  it  relied  on  pulling 
data  from  participating  systems,  processed  queries  individually  and  did  not  retain  the 
results.  GTN  Version  2.0  was  developed  to  solve  these  problems.  On  14  February  1992, 
Computer  Sciences  Corporation  (CSC)  delivered  Version  2  software,  manuals  and 
specifications.  Version  2.0  uses  participating  systems  to  “push”  information  to  a 
centralized  database.  This  allows  a  much  larger  number  of  customers  to  use  the  system 
without  significantly  increasing  interactive  load  on  the  supporting  systems. 

[Ref.  15:pp.  1-4] 

Version  2.0  was  also  the  first  attempt  to  combine  data  from  surface  systems 
owned  by  MTMC  and  air  systems  owned  by  AMC  to  provide  intransit  visibility  of 
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passengers  and  cargo  moving  between  the  U.S.  and  overseas  locations.  The  first  delivery 
of  Version  2.0  in  February  1992  had  numerous  problems.  Most  importantly,  Version  2.0 
could  not  stay  running  for  more  than  a  few  hours  and  returned  incorrect  information 
Consequently,  it  was  not  accepted  and  was  returned  to  CSC.  CSC  corrected  a  significant 
portion  of  the  problems  and  the  Government  accepted  the  improved  Version  2.0  on  22 
July  1992.  However,  this  version  was  not  released  for  operational  use  and  efforts  were 
directed  toward  developing  and  refining  requirements  for  Version  2.1. 

[Ref.  18] 

On  3  March  1992,  the  GTN  Program  Management  Office  (PMO)  was  officially 
formed  when  ASD  (C3I)  designated  GTN  a  Major  Automated  Information  System 
(MAIS)  program.  Prior  to  this,  GTN  was  an  internal  command  effort  under  the  Directors 
of  Operations  and  Logistics  (USTRANSCOM/TCJ3/TCJ4)  and  Command,  Control, 
Communications,  and  Computer  Systems  (USTRANSCOM/TCJ6).  [Ref.  19:pp.  1-2] 
Also,  due  largely  to  the  problems  related  to  Version  2.0,  it  was  apparent  that  a  single 
focal  point  for  GTN  development  was  needed.  One  of  the  PMO’s  primary  objectives 
would  be  to  integrate  the  functions  of  TCJ3/J4-G  and  TCJ6-G.  The  PMO  would  report 
directly  to  the  USTRANSCOM  Deputy  Commander-in-Chief  (DCINC).  [Ref.  18] 

Consequently,  between  14  September  1992  and  28  January  1993,  the  DCINC,  the 
Assistant  Secretary  of  the  Air  Force  for  Acquisition  (SAF/AQ),  and  the  Assistant 
Secretary  of  Defense  for  Command,  Control,  Communications,  and  Intelligence 
(ASD/C3I)  participated  in  discussions  that  resulted  in  the  SAF/AQ  signing  a 
memorandum  turning  over  GTN  program  management  responsibilities  to 
USTRANSCOM  (a  function  normally  performed  by  a  Service  vice  a  joint  command.)  In 
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addition,  the  memorandum  allowed  the  DCINC  to  establish  the  authority  of  the  PMO 
through  the  GTN  Program  Manager’s  Charter.  [Ref.  18] 

Responsibilities  and  accountability  outlined  in  the  charter  established  that  the  PM 
report  to  the  DCINC  for  overall  cost,  schedule,  and  performance  of  the  system  to  meet 
validated  requirements.  The  PM  was  responsible  for  establishing  and  maintaining  a 
Memorandum  of  Agreement  (MOA)  between  USTRANSCOM  and  the  Air  Force 
Materiel  Command’s  Electronic  Systems  Center  (AFMC-ESC).  In  accordance  with  the 
MOA,  ESC  was  to  provide  acquisition  support,  which  included  contract  preparation.  The 
PM  would  report  to  the  Designated  Acquisition  Commander  (DAC),  AFMC-ESC/CC  for 
acquisition  matters.  The  DAC  would  provide  acquisition  management  oversight  and 
report  to  SAF/AQ  regarding  all  acquisition  and  procurement  issues.  Other  PM 
responsibilities  included: 

•  Establish  a  process  for  obtaining  and  validating  requirements  for  the  GTN 
program  with  HQ  USTRANSCOM. 

•  Develop  an  acquisition  strategy  and  program  baseline. 

•  Budget  for  and  manage  the  funds  to  develop  and  field  the  GTN  program. 

•  Identify  life  cycle  costs  and  manpower  requirements. 

•  Establish  a  detailed  program  schedule. 

•  Manage  and  oversee  contracts  to  design,  develop,  test,  and  field  an  automated 
command  and  control  system  to  satisfy  GTN  requirements. 

PM  authority  included: 

•  The  PM  had  full  control  and  authority  over  all  approved  program  funds. 

•  The  PM  had  full  authority  to  communicate  with  Major  Commands  involved  in 
the  GTN  program.  These  Major  Commands  include  the  TCCs,  AMC, 

MTMC,  MSC,  Service  Headquarters,  the  supported  CINCs,  and  AFMC-ESC. 
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•  To  achieve  the  objectives  of  the  GTN  program,  the  PM  had  full  authority  to 
arrange  inter-service  support  agreements  or  MO  As  with  other  DOD  agencies. 

•  The  PM  had  the  authority  to  pursue  contracts  for  engineering,  Independent 
Verification  and  Validation  (IV&V),  testing,  and  business  services  support  to 
the  GTN  program  office.  [Ref.  20] 

During  the  time  frame  from  September  1992  through  January  1993,  the  TCGT 
produced  a  Mission  Element  Need  Statement  (MENS)  identifying  the  future  requirements 
of  the  GTN  system.  [Ref.  18] 

CSC  delivered  the  GTN  Version  2.1  prototype  in  March  1993  (figure  3).  Version 
2. 1  provided  intransit  visibility  for  all  passenger  and  cargo  lift  manifests  on  AMC’s 
organic  and  chartered  aircraft.  Due  to  the  prototype’s  success,  Version  2.1  was  fielded, 
on  a  limited  basis,  for  the  operational  community.  Version  2. 1  received  Military 
Standard  Requisitioning  and  Issue  Procedures  (MILSTRIP)  transactions  from  Defense 
Automated  Addressing  System  (DAAS)  and  used  this  information  to  link  the  requisition 
number,  national  stock  number  (NSN),  and  transportation  control  number  (TCN).  Using 
the  Headquarters  On-line  System  for  Transportation  (HOST)  network,  the  TCN  is  linked 
to  Advance  Transportation  Control  and  Movement  Document  (ATCMD)  data  received 
from  AMC  port  activities.  HOST  also  provides  some  unit  movement  data.  For  passenger 
movements,  AMC’s  Passenger  Reservation  and  Manifest  System  (PRAMS),  provides 
GTN  with  passenger  names  and  social  security  numbers.  The  GTN  also  receives  aircraft 
scheduling  information  from  AMC’s  Global  Decision  Support  System  (GDSS). 

[Ref.  15:pp.  1-4, 1-5] 

To  improve  the  reliability  and  responsiveness  of  the  system,  there  were  five 
maintenance  releases  during  1993.  During  this  time  frame,  CSC  worked  on  a  major 
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upgrade  of  the  GTN  prototype  for  delivery  in  January  1994.  The  upgrade  provided  the 
sealift  intransit  visibility  to  the  DOD.  [Ref.  21] 


DAAS  HOST  PRAMS  GDSS 


Figure  3.  GTN  Version  2.1  -  Air  Interfaces  [Ref.  15  :p.  1-5] 

Meanwhile,  the  GTN  PMO  worked  to  acquire  a  new  contract  to  fully  develop  the 
GTN,  and  on  18  May  1993,  the  GTN  Operational  Requirements  Document  (ORD)  was 
approved  by  USTRANSCOM.  The  ORD  defined  the  GTN  program  requirements.  The 
Major  Automated  Information  System  Review  Council  (MAISRC)  reviewed  the 
proposed  GTN  in  April  1993  and  issued  a  Systems  Decision  Memorandum  (SDM)  in 
May  that  officially  placed  the  program  in  Phase  I.  Tasking  was  assigned  to  be  completed 
prior  to  reaching  Milestone  n.  This  tasking  required  USTRANSCOM  to  prepare  a  draft 
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Life  Cycle  Cost/Benefit  Analysis  (LCC/BA)  in  September  1993.  The  final  version  would 
be  produced  by  USTRANSCOM  after  review  by  the  Office  of  the  Director  (OD) 

Program  Analysis  and  Evaluation  (PA&E).  Both  the  GTN  PM  and  OD  PA&E  agreed  on 
the  methodology  and  responsibilities  for  executing  a  cost  and  benefits  study  of  the  GTN. 
[Ref.  22:pp.  2-1] 

In  August  1993,  the  Joint  Transportation  Corporate  Information  Management 
(CIM)  Center  (JTCC)  was  tasked  to  improve  the  efficiency  and  effectiveness  of  the 
DTS  by  centrally  directing  transportation  information  systems  development  and 
migration,  applying  functional  process  improvement  techniques,  and  standardizing  data. 
[Ref.  23] 

The  DTS  systems  migration  effort  involved  eliminating  duplicate  systems 
capabilities  and  redirecting  systems  toward  hardware  independent  modules  with 
information  capabilities.  In  addition,  JTCC,  with  the  cooperation  of  the  joint 
transportation  community,  reviewed  core  DTS  business  processes.  Functional  process 
improvement  projects  were  undertaken  on  behalf  of  a  process  owner  and  took  an  end-to- 
end  view  toward  functional  process  improvement  across  Service  boundaries.  Problems 
relating  to  data  standardization  identified  in  the  DTS  related  to  non-standard  information 
systems  that  did  not  use  transportation  assets  efficiently  and  effectively.  In  order  to 
achieve  successful  systems  migration,  data  standardization  was  essential.  The  JTCC 
worked  to  develop  and  obtain  DOD  approval  of  transportation  data  standards  in  a 
transportation  logical  data  model.  All  of  these  efforts  significantly  enhanced  GTN 
development  and  effectiveness.  [Ref.  24:pp.  1-12] 
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USTRANSCOM  Commander-in-Chief,  General  Ronald  R.  Fogleman,  designated 
1994  as  the  “Year  of  Intransit  Visibility.”  By  proclaiming  the  intransit  visibility  theme, 
Gen.  Fogleman  sought  to  bring  together  the  different  efforts  going  on  in  DOD  and 
emphasize  the  importance  of  ITV  within  the  full  GTN  planning  and  development.  The 
prime  objective  for  the  year  was  to  identify  ITV  requirements,  develop  a  concept  of 
operations,  and  publish  a  comprehensive  integration  plan,  all  coordinated  with  DOD 
components.  [Ref.  25]  This  initiative  also  served  as  a  significant  impetus  for  further 
improving  the  GTN. 

During  1994,  there  were  several  GTN  prototype  enhancements.  Version  2.2  was 
delivered  in  January  and  provided  intransit  visibility  to  land  and  sea  shipments  in  much 
the  same  manner  as  Version  2. 1  provided  intransit  visibility  to  air  shipments.  As  in 
Version  2.1,  the  requisition  number,  NSN,  and  TCN  data  was  provided  by  DAAS. 
Transportation  control  movement  document  (TCMD),  booking,  and  other  shipment 
information  was  provided  by  MTMC’s  Worldwide  Port  System  (WPS),  Terminal 
Management  System  (TERMS),  and  Military  Export  Traffic  System  (METS II)  for 
surface  cargo  shipments  moving  between  POE  and  POD.  These  relationships  are  shown 
in  figure  4.  [Ref.  15:p.  1-5] 

GTN  Version  2.2.1  was  delivered  in  March  1994.  It  involved  maintenance  for  83 
incident  reports  and  included  five  new  functionalities.  These  functionalities  were 
Mission  Lock,  Surface  Wildcard,  NSN  Popup,  WPS  changes,  and  Installation 
Enhancements.  [Ref.  26] 

In  August  1994,  GTN  Version  2.3  was  delivered.  It  contained  seven  new 
capabilities  and  91  software  corrections.  These  new  capabilities  included: 
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•  GDSS  message  interface,  which  included  GDSS  updates  and  more  accurate 
GDSS  information. 

•  DODAAC  address  popup  that  included  unit,  mailing,  and  billing  addresses. 

•  Air  and  surface  queries  by  commodity  code  and  overview/pairs  location. 

•  The  ability  to  use  a  wildcard  TCN. 

•  Consolidated  of  requisitions  under  a  TCN. 

•  Changes  in  passenger  data  and  mission  schedule  displays. 

•  Several  corrections  for  the  System  Administrator  and  Functional  Data  Base 
Manager  (FDBM).  [Ref.  26] 


DAAS  WPS  TERMS  METS II 

Figure  4.  GTN  Version  2.2  -  Surface  Interfaces  [Ref.  15:p.  1-6] 

GTN  Version  2.3.1  was  delivered  in  December  1994  and  contained  four  new 
capabilities  and  21  Interface  Requirements  (IRs).  The  new  capabilities  included: 
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•  Accepting  data  from  the  new  GDSS  interface. 

•  GCCS  data  transfer. 

•  CDSS  interface. 

•  Global  Transportation  Network  Electronic  User  Interface  (GTNEUI) 

The  IRs  included: 

•  Show-manifest  for  GBLs. 

•  Truck  information. 

•  Queries  that  exceeded  the  15  minutes  response  time. 

•  Return  mail  on  queries  when  GTN  was  exited  before  the  query  was  complete. 

•  Accessing  the  Military  Standard  Transportation  and  Movement  Procedures 
(MILSTAMP)  Seaport  popup  in  Overview/Pairs. 

The  prototype  contract  with  CSC  expired  in  September  1994.  A  follow-on 
contract  for  prototype  maintenance/upgrades  was  awarded  in  September  1994  and  was 
scheduled  to  expire  in  March  1997.  [Ref.  26] 

F.  LIFE  CYCLE  COST/BENEFIT  ANALYSIS 

The  Office  of  the  Director  (OD)  Program  Analysis  and  Evaluation  (PA&E) 
reviewed  the  GTN  Life  Cycle  Cost/Benefit  Analysis  (LCC/BA)  draft  in  September  1993. 
The  final  version  was  subsequently  produced  in  January  1995.  The  LCC/BA  was  a 
driving  factor  in  obtaining  approval  for  production  system  development.  In  this  analysis, 
USTRANSCOM  compared  the  costs  and  benefits  of  two  different  options.  The  first 
option,  the  Status  Quo  Alternative,  involved  continuing  the  operational  prototype  (v.  2.3) 
through  fiscal  year  2010.  The  second  option,  the  Preferred  Alternative,  involved  the  full 
development,  implementation,  operations  and  support  [of  GTN]  through  fiscal  year  2010. 
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Operational  prototype  maintenance  would  continue  until  delivering  the  Preferred 
Alternative  Initial  Operational  Capability  (IOC),  slated  for  fiscal  year  1997.  OD  PA&E 
considered  other  options  infeasible,  impractical  or  unnecessary.  [Ref.  27:p.  2-2] 

Benefits.  The  primary  benefits  of  a  comprehensive  IT V  system,  such  as  GTN, 
are  enhanced  war  fighting  capability  and  reduced  operating  costs.  An  effective  ITV 
system  is  a  force  multiplier  because  it  gives  the  war-fighting  commanders  confidence  in 
their  logistical  support,  allowing  them  swift  and  decisive  moves.  Such  benefits  are 
difficult  to  quantify,  so  the  LCC/BA  addressed  the  issue  by  determining  a  value  of 
“Improved  Operational  Effectiveness.”  A  three-day  conference  was  held  at 
USTRANSCOM  in  June  1993  to  determine  the  types  of  benefits  to  be  used.  Participants 
at  the  meetings  discussed  the  situations  that  had  occurred  in  Operation  Desert 
Shield/Storm  and  other  operations  and  how  they  might  have  been  handled  differently  if 
the  capabilities  of  the  GTN  were  available.  A  second  conference  was  held  in  July  1993 
where  the  participants  constructed  detailed  estimates  of  specific  benefits  and  estimated 
the  dollar  value  of  these  benefits.  An  estimate  of  the  total  benefit  was  then  constructed. 
[Ref.  27:p.  2-3] 

Costs.  The  LCC/BA  for  GTN  cost  estimations  used  constant  FY95  dollars. 
Another  assumption  was  that  two  major  regional  conflicts  would  occur  during  the  service 
life  of  GTN.  The  LCC/BA  was  projected  from  FY97  through  FY10.  The  study  used 
1999  and  2005  as  the  major  regional  conflict  years  based  on  the  USTRANSCOM/J2-0 
“Hot-spots  1993”  briefing  and  the  USTRANSCOM  J2-0  “2010”  briefings.  These  two 
possible  contingencies  were  for  planning  purposes  only  and  were  anticipated  to  be  of  the 
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same  intensity  as  Desert  Shield/Storm.  A  greater  number  of  conflicts  would  add  to  the 
benefit  margin  and  a  smaller  number  of  conflicts  would  reduce  it.  [Ref.  27:p.  2-4] 
Analysis.  In  the  Life  Cycle  Cost/Benefit  Analysis  study,  the  Preferred 
Alternative  had  a  hard  cost  savings  of  $1,368  million,  with  an  additional  estimated  $193 
million  in  cost  avoidance.  Expert  opinion  valued  the  non-quantifiable  benefits  from  the 
Preferred  Alternative  at  $781  million.  The  future  development  and  maintenance  cost  for 
fielding  the  Preferred  Alternative  of  GTN  was  estimated  at  $422  million  through  FY10 
[Ref.  27:p.  2-5] 

The  Status  Quo  Alternative  would  cost  $66  million  through  FY2010  and  realize 
an  estimated  hard  cost  savings  of  $294  million.  The  Status  Quo  Alternative  discounted 
benefit/cost  ratio  was  4.39  compared  to  the  Preferred  Alternative  benefit/cost  ratio  of 
3.11.  However,  if  total  prior  year  costs  were  factored  into  the  benefit/cost  ratio,  the 
Preferred  Alternative  proved  superior  with  a  ratio  of  2.67  versus  the  Status  Quo 
Alternative  ratio  of  2. 10.  Both  alternatives  projected  a  break-even  point  of  FY99.  [Ref. 
27:p.  2-6]  These  results  are  summarized  in  Table  2. 

G.  MIGRATION  STRATEGY 

As  part  of  the  JTCC’s  migration  strategy,  which  began  in  1993,  the  JTCC 
proposed  a  new  baseline  to  reduce  functional  redundancy  among  systems.  [Ref.  28]  This 
resulted  in  fewer  individual  systems  and  increased  integration.  [Ref.  29:p.  1]  The  goal 
was  to  reduce  cost  and  increase  compatibility  between  transportation  information 
systems. 

Systems  associated  with  transportation  were  categorized  as  “legacy  systems”  or 
“migration  systems.”  A  legacy  system  was  defined  as  an  automated  information  system 
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that  performs  the  same  functions  as  those  performed  by  a  selected  migration  system. 
Legacy  systems  have  a  finite  life,  with  all  further  system  development  and 
modernization  resources  applied  to  a  selected  migration  system.  [Ref.  3:p.  B-l]  A 
migration  system  is  an  existing  system  that  has  already  been  developed  (or  is  being 


Table  2:  Life  Cycle  Cost/Benefit  Analysis  [Ref.  27:p.  2-6] 


LCC/BA  Recap 
(Actual  Dollars) 
as  of:  22  December  1994 

Constant 

Discounted 

$K 

$K 

Status  Quo  Alternative 

Total  Quantifiable  Benefit  (cum  savings): 

294,506 

238,903 

Total  Future  Year  Costs: 

66,515 

54,378 

Total  Prior  Year  Costs  (not  discounted): 

59,405 

59,405 

Total  Costs  (cum): 

125,922 

113,783 

Net  Present  Value  =  PV  Benefits  -  PV  Costs: 

184,525 

Benefit/Cost  Ratio  PV: 

4.39 

Benefit/Cost  Ratio  (cum): 

2.10 

Break  Even  Year: 

FY99 

Preferred  Alternative 

Total  Quantifiable  Benefit  (cum  savings): 

1,368,431 

1,112,167 

Total  Future  Year  Costs: 

422,461 

357,789 

Total  Prior  Year  Costs  (not  discounted): 

59,405 

59,405 

Total  Costs  (cum): 

481,866 

417,194 

Net  Present  Value  =  PV  Benefits  -  PV  Costs: 

754,378 

Benefit/Cost  Ratio  PV: 

3.11 

Benefit/Cost  Ratio  (cum): 

2.67 

Break  Even  Yean 

FY99 

developed/enhanced),  and  is  officially  designated  to  support  standard  processes. 

[Ref.  3:p.  B-2] 

By  early  July  of  1994,  the  JTCC  had  found  a  total  of  137  systems  using 
transportation  information  [Ref.  28].  Of  these  systems,  some  had  their  primary  function 
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outside  of  transportation.  As  of  September  1999, 23  systems  were  approved  for 
migration  and  22  systems  remained  as  legacy  systems.  Appendix  A  gives  a  brief 
description  of  the  23  migration  systems  and  Appendix  B  lists  the  migration  systems, 
legacy  systems,  and  termination  dates.  [Ref.  30] 

To  ensure  only  the  best  systems  were  included  in  the  migration  strategy,  the 
process  of  selecting  a  system  was  very  involved.  Aspects  of  the  legacy  systems  were 
normally  incorporated  in  the  surviving  migration  systems.  The  process  of  selecting  a 

k 

migration  system  began  by  grouping  migration  candidates  into  one  of  nine  categories. 
Each  migration  candidate  was  then  evaluated  on  the  basis  of  functional  coverage, 
technical  merit,  and  programmatic  requirements  [Ref.  29:p.  5].  After  evaluating  each 
candidate,  an  Integration  Decision  Paper  (DDP)  was  prepared  for  each  functional 
category,  which  recommended  the  migration  systems  and  the  lead  agency  for  each 
system.  The  EDP  was  then  sent  to  the  Office  of  the  Secretary  of  Defense  (OSD)  for 
review  and  approval.  When  approved,  the  lead  agency  developed  a  System  Decision 
Paper  (SDP).  The  SDP  contained  detailed  requirements  of  tasks,  responsibility, 
estimated  resources  required,  and  milestones  and  metrics  for  the  development  efforts. 
The  SDP  was  then  sent  to  OSD  for  approval.  Once  approved,  the  lead  agency  began 
migration  system  development  and  implementation.  [Ref.  29:p.  2]  A  summary  of  the 
nine  functional  categories,  the  23  migration  systems,  and  the  lead  agency,  are  listed  in 
Table  3. 
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Table  3:  Migration  Summary 


Category 

Num 

System 

Lead  Agency 

Unit  Move 

1 

TC-A1MS  n 
(TC-AIMS/MDSS 

ID 

USA 

ITO/TMO 

TC-AIMS  n 
(CMOS) 

USA 

2 

CFM 

MTMC 

3 

CANTRACS 

DLA 

4 

TOPS 

MTMC 

5 

GATES 

AMC 

6 

GOPAX 

MTMC  | 

Load  Planning 

7 

AALPS 

MTMC 

8 

ICODES 

MTMC 

Port  Management 

GATES 

AMC 

9 

WPS 

MTMC 

Financial  Mgt 

10 

FACTS 

USN 

Mode  Clearance 

11 

IBS 

MTMC 

12 

MOBCON 

USANG 

Theater  Trans  Ops 

TC-AIMS  n 

USA 

13 

C2IPS 

AMC 

Planning/Execution 

r  14 

CAMPS 

AMC 

15 

GDSS-MLS 

AMC 

GATES 

AMC 

C2IPS 

AMC 

16 

GTN 

USTC 

17 

ELIST 

MTMC 

18" 

AMS  (MTMC) 

MTMC  | 

19 

IC3 

MSC 

Other 

20 

JALIS 

USN 

21 

DTTS 

USN 

22 

ACAS 

AMC 

23 

TRAC2ES 

USTC 

H.  PRODUCTION  SYSTEM  SOURCE  SELECTION 

The  Request  for  Proposal  for  the  operational  version  of  the  GTN  was  put  together 
in  the  first  four  months  of  CY94.  The  package  included  the  System  Specification,  the 
Statement  of  Work,  proposal  preparation  instructions,  evaluation  factors  for  award, 
contract  data  requirements  list,  contract  clauses,  and  other  special  instructions.  The  RFP 
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was  released  on  5  May  1994  and  proposals  were  received  on  1  July.  The  proposals  were 
evaluated  beginning  6  July  and  proceeded  throughout  remainder  of  the  year.  [Ref.  26] 

On  23  Mar  95,  the  GTN  Operational  System  contract  was  awarded  to  UNISYS 
Government  Systems  Group.  However,  due  to  protests  by  two  unsuccessful  offerors, 
final  determination  was  delayed  until  14  August  1995.  The  six-year  contract  had  a 
potential  value  of  $62.5  million  and  was  to  be  delivered  in  five  phases  stretching  over  a 
four-year  period.  Fourteen  months  after  contract  award,  UNISYS  was  scheduled  to 
deliver  a  system  (Delivery  1)  for  Initial  Operational  Test  and  Evaluation.  Delivery  1  was 
to  provide  initial  ITV  capabilities.  Delivery  2  would  provide  automation,  modeling,  and 
simulation  tools  to  support  current  operations  and  switch  from  a  client-server  to  a  web- 
based  architecture.  Delivery  3  would  provide  automation,  modeling,  and  simulation  tools 
to  support  current  &  future  operations.  Delivery  4  would  field  five  deployable  sets  of 
equipment  to  provide  GTN  capabilities  to  the  supported  CINC.  Delivery  5  would 
provide  the  last  of  current  operations  functionality,  and  a  set  of  automation,  modeling, 
and  simulation  tools  to  support  future  operations  and  patient  movement.  [Ref.  31] 

Loral  Defense  Systems-East  purchased  UNISYS  Government  Systems  Group  in 
May  95.  [Ref.  32]  Loral,  now  the  prime  contractor  for  the  GTN,  coordinated  the  work  of 
six  subcontractors.  Encompass  provided  the  same  kind  of  logistics  software  it  provides 
to  corporate  users.  GTE  provided  communications  and  security  services  for  the  network, 
ISX  developed  the  user  interface  with  the  GTN,  Digital  Equipment  provided  the  client- 
server  equipment,  and  Andrulis  and  Innolog  provided  their  logistics  functional  expertise. 
[Ref.  33] 
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Milestone  II  Review  was  successfully  conducted  and  the  Milestone  II  System 
Decision  Memorandum  was  issued  on  19  Sep  95.  Other  approved  documents  included 
the  revised  GTN  Operational  Requirements  Document  (ORD)  dated  30  Jan  95,  GTN  Test 
and  Evaluation  Mater  Plan  (TEMP)  dated  30  Jan  95,  and  the  GTN  Program  Management 
Directive  (PMD)  dated  1  Jul  95.  [Ref.  32] 

Lockheed  Martin  Corporation  purchased  Loral  Defense  Systems-East,  effective 
29  April  1996.  As  a  result  of  delivery  delays  from  Encompass,  unplanned  Bosnia  support 
activities,  post-System  Acceptance  Test  (SAT)  operational  support,  and  external  interface 
re-engineering,  the  cost  of  the  Lockheed  Martin  GTN  Development  Contract  increased 
by  $2.7  million  in  1996.  [Ref.  34] 

Test  Readiness  Review  was  performed  in  September  1996,  and  formal  (SAT)  was 
performed  in  October  1996.  The  Air  Force  Operational  Test  and  Evaluation  Center 
(AFOTEC)  completed  GTN’s  Initial  Operating  Test  and  Evaluation  (IOT&E)  in 
December  1996.  [Ref.  34] 

Several  other  reviews  were  performed  throughout  1996.  A  Delivery  1  System 
Design  Review  (SDR)  was  conducted  in  March  1996,  while  a  Systems  Requirements 
Review  (SRR)  was  accomplished  with  meetings  in  March,  April,  and  May  of  1996.  A 
Software  Process  Assessment  (SPA)  was  performed  in  March,  two  Joint  Program 
Management  Reviews  (JPMRs),  one  in  June  and  one  in  December,  were  hosted,  and 
several  Technical  Interchange  Meetings  (TIM)  were  held  throughout  1996.  These 
reviews  and  meetings  discussed  many  GTN  aspects,  including  schedule,  progress, 
hardware  status,  system  components,  system  enhancements,  external  interfaces,  increased 
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command  and  control  capability,  and  commercial  Electronic  Data  Interchange  (EDI). 
[Ref.  34] 

A  pre-IOC  version  of  GTN  was  fielded  by  USTRANSCOM  to  selected  US  Army, 
Europe  (USAREUR)  activities  in  October  1996  to  assist  in  Operation  Joint  Endeavor. 
USTRANSCOM  provided  limited  on-site  training  at  the  time  of  this  fielding. 

USAREUR  units  were  scheduled  for  formal  fielding  and  training  during  February  and 
March  1997.  [Ref.  34] 

Two  versions  of  the  GTN  were  originally  fielded.  The  first  version  was  an 
Internet  Web  site  for  registered  users  with  common  network  browser  software.  The 
second  version  was  a  client/server  application,  which  required  the  user  to  have  a  software 
package  installed.  The  Web  Site  version  performed  simple  one-time  queries,  while  the 
client/server  version  performed  more  complex,  repetitive  queries.  Due  largely  to 
technological  improvements  and  lessons  learned  from  Operation  Joint  Endeavor,  further 
GTN  development  began  to  focus  more  heavily  on  Web  technology.  Subsequently,  less 
effort  was  spent  on  developing  the  client/server  version.  [Ref.  35] 

I.  DEFENSE  TRANSPORTATION  ELECTRONIC  DATA  INTERCHANGE 

(DTEDI) 

EDI,  using  communications  standards  jointly  developed  with  the  commercial 
sector,  processes  ITV  information  through  the  GTN.  A  standardized  EDI  interface,  both 
DOD  and  commercial,  is  essential  to  providing  reliable  ITV  information  through  the 
GTN. 

On  18  Jan  95,  the  Deputy  Under  Secretary  of  Defense  for  Logistics  (DUSD(L)) 
designated  USTRANSCOM  as  the  lead  agent  to  accelerate  and  expand  EDI 
implementation  to  support  of  DOD  transportation.  To  accelerate  EDI  implementation 
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within  DOD  and  with  the  commercial  carrier  industry,  a  DTEDI  Program  Implementation 
program  was  developed  by  USTRANSCOM  and  finalized  on  4  Jun  96.  This  program 
prescribed  aggressive  schedules  to  accomplish  the  implementation  goals.  It  described  15 
EDI  projects  within  four  areas  of  transportation:  tender  submission,  planning,  movement, 
and  payment.  [Ref.  36] 

In  March  1996,  USTRANSCOM  was  designated  to  be  the  Test  Director  for 
Systems  Integration  Testing  (SIT)  for  the  transportation  billing  and  payment  processes. 
SIT  was  performed  in  two  phases.  Phase  I  used  canned  data  in  a  test  environment,  and 
phase  II  used  production  data  transmitted  by  the  shipper  systems  to  process  Government 
Bills  of  Lading  (GBLs),  with  DFAS  making  payments  using  EDI  techniques.  Phase  II 
began  in  August  1996.  [Ref.  36] 

J.  AUTOMATIC  IDENTIFICATIN  TECHNOLOGY  (AIT) 

DOD  incorporated  sophisticated  AIT  devices  during  operations  in  Somalia,  Haiti, 
and  Bosnia.  However,  a  Joint  Logistics  ATT  Concept  of  Operations  and  Implementation 
Plan  had  yet  to  be  developed.  To  ensure  an  integrated  approach  to  ATT  within  DOD,  the 
Office  of  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology  established  an 
AIT  task  force  on  7  January  1997.  The  goal  of  the  task  force  was  to  develop  an  AIT 
Concept  of  Operations  that  addressed  all  the  logistics  processes  that  require  collecting 
information  about  the  identity  and  status  of  material  throughout  the  logistics  chain.  [Ref. 
37] 

ATT  is  a  critical  component  of  ITV/TAV  and  the  GTN.  The  strength  of  ATT,  as 
an  enabling  technology,  is  its  ability  to  capture  data  rapidly  and  accurately,  and  transfer 
the  data  to  Automated  Information  Systems  (AISs)  automatically  with  little  or  no  human 
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intervention.  [Ref.  38:p.  2-7]  The  Joint  Total  Asset  Visibility  (JTAV)  Office  has  been 
established  to  ultimately  provide  a  central  AIS,  which  will  encompass  all  of  the  various 
Services.  One  of  the  functions  provided  from  the  central  database  is  aggregating  and 
storing  information  that  is  gathered  from  the  various  ATT  devices  throughout  DOD.  The 
GTN  will  ultimately  include  the  central  repository  for  ATT  data  that  will  provide  GTN 
users  with  ITV/TAV.  [Ref.  37] 

K.  GTN  INITIAL  OPERATING  CAPABILITY  (IOC) 

Initial  Operating  Capability  of  the  GTN  was  initially  expected  in  November  1996, 
but  was  delayed  until  March  1997  due  to  problem  delays  originating  with  Encompass  and 
schedule  slips.  Encompass  made  a  corporate  decision  early  in  1996  to  redesign  their 
commercial  application  object  model,  which  caused  the  delay.  As  a  result,  Delivery  1  was 
delayed  overall  from  May  96  to  Oct  96.  [Ref.  39]  Following  Delivery  2,  the  original 
Deliveries  concept  was  changed.  The  five  Deliveries,  as  originally  planned,  were  large 
functional  additions,  which  were  deemed  to  be  relatively  unmanageable.  It  was 
considered  advantageous  to  break  the  Deliveries  into  smaller  groups  of  functionalities 
that  could  be  developed  and  managed  more  efficiently.  [Ref.  40] 

In  March  1997,  after  reaching  IOC  for  the  production  system,  the  GTN  prototype 
maintenance  contract  with  CSC  was  terminated.  Additionally,  a  feasibility  study  was 
performed  to  determine  if  USTRANSCOM’s  Global  Command  and  Control  System  and 
collateral  local  area  network  should  move  to  the  regional  Defense  Megaenter  (DMC)  in 
St.  Louis,  MO.  The  results  of  the  study  confirmed  the  move,  and  plans  were  made  to 
execute  the  move  in  1998.  [Ref.  39] 
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In  1997,  the  value  of  the  Lockheed  Martin  GTN  Development  Contract  increased 
by  $48.6M.  The  majority  of  the  increase  reflected  two  Capital  Purchase  Program  funding 
authority  awards.  These  awards  covered  unfunded  requirements,  including  new  system 
requirements  and  increased  capabilities  defined  by  the  functional  user  community.  The 
increased  capabilities  included  a  Windows  NT  environment,  a  Common  Transportation 
Server,  integration  of  commercial  carrier  movement  information  via  Electronic  Data 
Interchange  (EDI),  and  migration  to  a  Web-based  user  architecture. 

[Ref.  39] 

Intransit  visibility  capability  became  operational  in  1997;  by  December,  the  GTN 
had  a  data  warehouse  including  over  43  gigabytes  of  information.  The  GTN  also  had  the 
capability  to  post  approximately  80  percent  of  information  received  within  five  minutes 
of  receipt,  and  to  replicate  it  within  seconds.  [Ref.  41]  During  April  1998,  the  GTN 
discontinued  support  of  the  client/server  in  favor  of  the  web-based  systems  approach. 

This  gave  system  users  better  logistics  support  while  reducing  overall  program  costs. 
Transaction  volume  increases  and  additional  functionality  made  it  necessary  to  upgrade 
GTN  hardware  at  Scott  AFB  and  at  the  DMC.  These  hardware  upgrades  made 
Commercial  Electronic  Data  Interchange  (CEDI)  interface  implementation  possible. 

Three  initial  carriers  were  interfaced  to  the  GTN  via  CEDI  implementation.  SeaLand 
(ocean),  CSXT  (rail),  and  FedEx  (air)  were  successfully  integrated  with  existing  GTN 
data  in  May  1998.  [Ref.  42] 

Carrier  links  to  the  GTN  via  CEDI  will  help  military  shipments  planning,  improve 

1 

readiness  and  combat  capability,  and  reduce  duplicate  ordering.  Carriers  feed  shipment 
data  to  CSX  Integrated  Services  (CSX  Corp.’s  technology  arm)  where  the  data  is  recoded 
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into  a  generic  format.  The  data  is  then  transmitted  to  the  GTN  for  the  network’s  4,000 
military  users.  [Ref.  43]  There  were  24  CEDI  carriers  by  the  close  of  1998.  Other 
carriers  linked  to  the  GTN,  in  addition  to  the  three  named  above,  include  the  following  in 
alphabetical  order: 

1.  ABF  Freight  Systems 

2.  American  President  Lines 

3.  Baggett  Transportation  Co. 

4.  Burlington  Air  Express  (BAX  Global) 

5.  Cl  Whitten 

6.  Diablo  Transportation,  Inc. 

7.  Emery  Worldwide 

8.  Green  Valley  Transportation  Inc. 

9.  J.B.  Hunt 

10.  Landstar  Ranger  Inc. 

11.  Lykes  Line  Limited 

12.  Mercer  Transportation  Co. 

13.  Nations  Way  Transport  Service,  Inc. 

14.  Old  Dominion  Freight  Line 

15.  Ovemite  Transportation 

16.  Roadway  Express 

17.  Preston  Trucking 

18.  Trism  Specialized  Carriers 

19.  Tri-State  Motor  Transit  Company 

20.  Union  Pacific  Railroad 

21.  Yellow  Freight  System  (History  98, 1999) 

In  May  1998,  the  GTN  was  further  enhanced  by  the  Transportation  Coordinator’s 
Automated  Information  for  Movement  System  II  (TC AIMS -II)  and  Radio  Frequency  Tag 
(RF-TAG)  interface.  This  interface  provided  the  ability  to  access  advanced 
transportation  control  movement  documentation  via  the  GTN,  as  well  as  passenger  and 
cargo  movement  data  within  the  European  theater.  [Ref.  42] 

In  support  of  Operation  Desert  Fox,  Lockheed  Martin  installed  what  was  called 
the  Command  and  Control  (C2)  Tracker  on  the  GTN  operational  database  in  December. 
The  C2  Tracker  is  a  predetermined  set  of  data  fields  within  GTN,  enabling  users  to  press  a 
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single  button  and  enter  minimal  qualifiers  to  receive  required  data.  Throughout  1998, 
great  efforts  were  made  to  ensure  the  GTN  was  Year  2000  (Y2K)  compliant.  The  Y2K 
certification  letter  was  signed  in  December  1998.  [Ref.  42]  As  of  October  1999,  only 
three  of  the  migration  systems  had  yet  to  be  certified  for  Y2K  compliance  (FACTS,  TC- 
AIMS  n,  and  TRAC2ES).  [Ref.  30] 

L.  CURRENT  (2000)  GTN  VISION 

USTRANSCOM’s  current  vision  of  GTN  is  to  combine  DTS  customers  and  lift 
providers  into  a  single  integrated  network.  The  network  will  support  customer  needs  by 
providing  ITV,  command  and  control  (C2),  and  improved  information  that  facilitates 
better  management  of  warfighting  and  logistics.  GTN  will  also  serve  to  integrate  DOD’s 
transportation  processes  and  commercial  automated  transportation  systems  to  the 
maximum  extent  possible.  Electronic  Commerce  (EC)/Commercial  EDI  (CEDI)  will  be 
used  as  the  technology  to  provide  ITV  for  DoD  cargo  moving  via  commercial  carrier, 
estimated  to  be  as  high  as  80  percent  of  all  DTS  movements.  [Ref.  10:p.  2] 

Figure  5  provides  a  basic  view  of  the  transportation  process  and  how  GTN  fits 
into  that  process.  The  process  is  initiated  by  planning  passenger,  cargo,  and  patient 
transportation  requirements.  A  movement  requirement  is  then  generated  and  submitted 
for  item(s)  that  need  to  be  transported.  The  requirement  is  differentiated  by  passengers  or 
cargo,  shipment  planning  performed,  mode  selection,  and  commercial  or  military  lift. 
Transportation  assets  are  then  scheduled  to  move  the  required  personnel  and  cargo. 
Movement  is  then  initiated  and  tracked  intra-CONUS  from  origin  to  Port  of  Embarkation 
(POE),  through  intertheater  to  the  Port  of  Debarkation  (POD),  and  intratheater  to  the  final 
destination.  [Ref.  44:p.  15] 
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Embarkation 


Debaifcab'on 


Figure  5.  DTS  DataFIow  with  GTN  [Ref.  44:p  18] 


GTN  will  capture  data  at  selected  points  in  the  transportation  process.  The  data 
will  primarily  consist  of: 

•  Supply,  cargo,  forces,  passenger,  and  patient  requirements 

•  Schedules  and  movements  of  airlift,  air  refueling,  aeromedical  evacuation, 
and  surface  lift  (land  and  sea) 

•  Closure  estimates  as  provided  by  future  operations,  location,  and 
operational  status  of  transportation  assets 

•  Operational  plan  data 

•  Transportation  infrastructure  information 

This  data  is  collected  from  the  various  source  systems  into  an  integrated  database  (see 
figure  6).  This  database  will  provide  the  necessary  ITV,  C2,  and  business  operations 
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applications  and  information  to  the  user.  The  users  include  USTRANSCOM  and  the 
TCCs,  DoD,  Joint  Staff,  unified  commands,  defense  agencies,  and  the  Military  Services. 
[Ref.  44:pp.  16-19] 
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Figure  6.  GTN  Concept  [Ref.  45] 
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M.  CHAPTER  SUMMARY 


Earlier  success  with  “proof  of  concept”  GTN  prototypes  set  the  stage  for 
developing  operational  prototypes.  As  GTN  sophistication  and  capability  increased,  so 
did  the  responsibilities  of  USTRANSCOM.  A  number  of  challenges  had  to  be  overcome 
to  provide  the  robust  capabilities  to  meet  DTS  customer  needs.  However,  until  February 
1992,  USTRANSCOM  did  not  have  the  peacetime  authority  to  enforce  system 
compatibility,  data  standardization,  training,  and  documentation.  These  were  some  of  the 
major  impediments  to  system  development.  The  Gulf  War,  in  particular,  highlighted  the 
lack  of  ITV  and  the  critical  need  for  it.  Once  USTRANSCOM  was  granted  this 
authority,  the  90’ s  proved  to  be  an  unprecedented  decade  for  GTN  development. 

The  capabilities  of  the  operational  prototypes  increased  steadily. 

USTRANSCOM  implemented  a  number  of  initiatives  to  incorporate  user  needs  and  take 
full  advantage  of  evolving  technology.  Pull  systems  gave  way  to  push  systems.  Surface, 
air,  and  sea  capabilities  were  added.  Client  server  architectures  were  replaced  with  Web- 
based  technology.  A  number  of  key  management  and  infrastructure  changes  were  also 
implemented.  In  addition,  numerous  initiatives  were  implemented  that  aided  in 
development.  These  initiatives  included  data  standardization,  migration  strategies,  ITV, 
JTAV,  DTEDI,  AIT,  EB/CEDI,  and  life  cycle  costs/benefits  analyses. 

The  contract  for  the  GTN  production  system  was  awarded  in  1995.  New 
capabilities  and  functionalities  were  continually  enhanced  throughout  the  1990’s. 
Questions  continually  arose  concerning  the  future  of  the  GTN. 
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IV.  GTN  FUTURE 


A.  INTRODUCTION 

Evolving  technologies  have  considerable  potential  to  impact  the  GTN  in  ways 
never  before  imagined.  Advances  in  biotechnology  and  health  sciences  offer  the 
potential  to  significantly  increase  the  length  of  human  life.  The  revolution  in  information 
technology  has  been  no  less  spectacular.  Miniaturized  computers  that  fit  into  a  pair  of 
eyeglasses  and  possess  significantly  more  power  than  desktop  PCs  are  standing  by  ready 
for  production  and  distribution.  In  the  race  for  global  competitiveness,  this  revolution 
also  provides  the  competitive  edge  and  economies  of  scale  never  before  possible.  This 
revolution  should  be  no  less  significant  in  the  evolution  of  the  GTN.  In  addition  to 
providing  a  competitive  edge,  it  also  provides  the  potential  for  DOD  to  accomplish  its 
mission  with  the  highest  efficiency  and  at  the  lowest  possible  cost  -  both  in  assets  and  in 
human  life. 

B.  CUSTOMER  SURVEY 

USTRANSCOM  retained  American  Management  Systems  (AMS)  to  conduct  the 
FY99  USTRANSCOM  Customer  Survey  as  part  of  USTRANSCOM’ s  customer  outreach 
program.  The  survey  was  administered  to  key  USTRANSCOM  customers  to  determine 
customer  satisfaction,  identify  customer  requirements,  and  provide  recommendations  for 
improvements.  The  survey  was  assembled  through  information  gathered  from  mail  and 
e-mail  surveys  and  personal  interviews.  [Ref.  46:p.  3] 

In  general,  customers  viewed  USTRANSCOM’ s  service  as  adequate.  Although 
the  survey  sought  feedback  on  USTRANSCOM  as  a  whole,  some  insights  into  the  GTN 
performance  and  progress  were  obtained.  The  CINCs  rated  the  IT  systems  of  which 
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GTN  was  one,  as  valuable  to  their  organizations,  but  voiced  concern  that  GTN  does  not 
provide  the  ability  to  track  all  cargo  100%.  The  survey  sighted  a  possible  cause  of  the 
lack  of  visibility  was  operators,  at  all  levels,  not  inputting  data  into  the  GTN  in  a  timely 
manner.  The  services  believed  that  ITV  has  come  a  long  way  but  still  has  much  farther  to 
go.  The  respondents  suggested  that  more  integration  of  GTN  systems  that  would 
eliminate  redundancy  and  streamline  information  flow  would  improve  GTN 
effectiveness.  [Ref.  46:pp.  12-21] 

Shippers,  on  the  other  hand,  did  not  give  GTN  as  high  a  rating  sighting  the  GTN 
as  ineffective  compared  to  the  carriers  systems.  Shippers  did  not  understand  why  the 
carriers  systems  feeding  the  GTN  were  accurate  and  timely,  but  the  GTN’s  data  was  not 
the  same.  Shippers  would  prefer  that  the  GTN  information  be  just  as  accurate  as  the 
earner’s  data.  If  the  GTN  data  was  as  reliable  as  the  carriers’  data,  the  shippers  could  use 
only  the  GTN  rather  than  a  number  of  different  carriers’  data  systems.  [Ref.  46:p.  22-26] 

Part  of  the  challenge  for  the  GTN  is  that  it  is  fed  by  a  large  number  of  feeder 
systems.  The  difference  between  a  feeder  system’s  data  and  the  data  available  in  the 
GTN  is  that  the  GTN  has  to  be  updated  with  data  from  the  feeder  systems,  therefore  a  lag 
time  is  inherent  between  the  feeder  system  and  the  GTN.  One  of  the  goals  for  future 
GTN  planning  should  be  to  shorten  the  gap  between  the  data  available  from  the  carrier 
and  the  data  available  to  the  GTN  customer. 

C.  END  STATE 

As  the  GTN  evolved  from  inception  to  the  present  time,  it  became  clear  that 
rapidly  changing  technologies  made  it  almost  impossible  to  define  the  GTN  end  state. 
Timelines  were  periodically  updated  as  new  information  and  transportation  technologies 
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emerged  making  it  necessary  to  change  the  plan  with  respect  to  the  development  of  the 
GTN.  As  a  result,  the  GTN  is  now  seen  as  a  work  in  progress  with  no  foreseeable  end 
state.  The  GTN  will  continue  to  evolve  with  technology. 

There  does  exist  a  solid  plan  for  the  near  future.  The  following  timeline  shows 
the  plan  for  continued  development  of  the  GTN  through  FY04.  [Ref.  47] 


Figure  7.  Functionality  Improvements/Timeline  [Ref.  47] 
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Functionality  Improvements,  FY00-04 

Mar  00  -  Infrastructure  performance  enhancements  increasing  system’s  responsiveness. 

Apr  00-32  commercial  carriers  migrated  to  the  Joint  Electronic  Commerce  Program  Office 
Value  Added  Network.  Results  in  visibility  of  over  63%  of  cargo  moving  via  air,  rail,  motor 
GBL’s  and  91%  of  sea  containers. 

May  00  -  Improved  sealift  screenfaces  and  data  quality.  User  will  have  access  to  unclassified 
sealift  schedules.  Customization  will  enable  an  alert  function  where  GTN  will  notify  users  of  a 
particular  pre-programmed  event. 

Jun  00  -  Development  of  multiple  on-hand  values;  performance  enhancements  and  worldwide 
express  carrier  query. 

Sep  00  -  New  interface  with  USMC’s  LOGAIS.  Improvements  in  the  C2  reports  and  initial 
analysis  on  JOPES  S&M  module.  Direct  Vendor  Delivery  pharmaceutical  query  becomes 
operational. 

Oct  00  -  Incorporation  of  additional  commercial  carrier  EDI  information.  Reduction  of  data 
elements  in  support  of  MRM15  initiatives. 

Dec  00  -  New  interfaces  with  TCAIMS II  and  TRAC2ES. 

Mar  01  -  Direct  Vendor  Delivery  repair  parts  query  becomes  operational. 

Aug  01  -  New  interfaces  with  JFAST,  BDSS,  ADANS  and  AMP. 

Sep  01  -Exercise  Database  becomes  operational,  JOPES  S&M  Phase  I  delivered,  improved 
screenfaces  and  dynamic  alerts.  Improvements  in  NSN  Tables  and  WPS  transactions. 

Sep  01  -  Oct  03  -  Miscellaneous  minor  maintenance  improvements. 

Oct  03  -  Delivery  of  new  database. 

Oct  04-  Assorted  functionality  improvements. 


Figure  8.  Functionality  Improvements/Timeline  [Ref.  47] 


D.  BUILDUP  ANALYSIS 

In  the  past,  before  sending  American  soldiers,  sailors,  and  airmen  into  harms  way 
to  fight  a  war,  it  was  necessary  to  amass  huge  amounts  of  support  material  near  the 
theater  of  operations.  Not  until  it  was  certain  that  forces  going  into  battle  had  the  needed 
support  and  could  be  sustained  for  as  long  as  deemed  necessary  to  win  the  war,  did  the 
operational  commanders  feel  confident  about  engaging  their  forces  in  combat.  In  recent 
years,  the  military  and  the  American  public  have  become  intolerant  to  personnel 
casualties,  and  the  idea  of  sending  American  youth  to  their  deaths  in  support  of  a  political 
ideal  has  become  unacceptable. 
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It  took  six  months  to  buildup  enough  equipment,  supplies,  and  personnel  during 
Operation  Desert  Shield  before  Operation  Desert  Storm  could  commence.  From  the 
beginning  of  Operation  Desert  Shield  on  7  Aug  1990  to  the  commencement  of  hostilities 
and  Operation  Desert  Storm  on  17  January  1991, 439,553  personnel  and  7,276,092  tons 
of  cargo  were  deployed  to  the  Gulf.  [Ref.  16:p.  13] 

It  is  quite  possible  that  combat  forces  needed  that  much  cargo  and  personnel  for 
the  duration  of  the  war  but  did  not  need  that  much  cargo  and  personnel  to  begin  the  war. 
If  operational  commanders  felt  they  could  engage  the  enemy  sooner  with  just  enough 
resources  for  a  relatively  short  time,  with  the  confidence  that  resources  would  be  at  their 
disposal  when  needed,  numerous  advantages  would  be  realized.  If  the  U.S.  took  less  time 
to  build  up  resources,  the  enemy  would  have  less  time  to  prepare  for  war.  If  huge 
amounts  of  material  did  not  need  to  be  staged  prior  to  war  and  material  could  be  routed 
closer  to  a  moving  force  as  the  war  progressed,  the  added  flexibility  would  give 
operational  commanders  a  strategic  edge  that  previously  was  not  at  their  disposal. 

One  of  the  primary  functions  of  the  GTN  should  be  to  provide  the  operational 
commanders  with  the  confidence  that  through  TAV  of  personnel  and  material,  support 
will  be  at  the  right  place  and  time.  If  this  capability  were  available  during  Desert  Storm, 
it  is  possible  that  the  time  for  support  buildup  could  have  been  months  shorter.  Because 
the  outcome  of  Desert  Storm  was  so  overwhelming,  the  months  that  could  have  been 
saved  by  a  fully  developed  GTN  might  not  have  made  much  difference.  If  this  capability 
were  available  prior  to  the  beginning  of  World  War  n,  however,  the  time  saved  in 
building  up  for  D-Day  could  have  made  the  war  in  Europe  much  shorter.  Having  such 
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capability  in  the  future  will  prove  most  valuable  when  it  is  necessary  to  engage  a  more 
formidable  foe  and  do  so  in  an  expedient  manner  to  quickly  gain  the  upper  hand. 

E.  FUTURE  GTN  CAPABILITIES  -  AN  OPERATIONAL  SCENARIO 

The  GTN  of  the  future  should  be  one  of  the  most  valuable  resources  available  to 
senior  leadership  and  operational  commanders  during  peacetime  and  war.  An  operational 
commander  should  be  able  to  enter  the  GTN,  and  with  the  proper  clearance,  be  able 
access  all  information  concerning  movement  of  personnel,  equipment,  and  supplies 
throughout  the  world.  One  of  the  ways  future  GTN  capabilities  can  be  applied  to  satisfy 
the  following  scenario  can  illustrate  an  operational  need  in  the  future: 

Rebels  have  attacked  the  government  building  of  one  of  our  allies  (Country  X) 
and  it  is  urgent  that  the  U.S.  react  swiftly  before  the  rebels  gain  momentum.  It  is  decided 
that  U.S.  troops  will  be  sent  in  from  an  amphibious  ready  group  off  the  coast,  and  within 
48  hours  reinforcements  are  scheduled  to  arrive  from  CONUS.  The  original  plan.  Plan  A, 
called  for  the  use  of  conventional  ground  forces  and  is  scheduled  to  take  at  least  five 
months  but  will  result  in  minimal  U.S.  casualties.  Plan  B  is  an  alternative  plan  that  is 
more  aggressive  and  could  save  much  time  but  has  the  potential  of  significant  U.S. 
casualties. 

After  initial  contact  with  the  rebels,  the  commander  of  U.S.  forces  in  Country  X 
makes  an  assessment  of  the  situation  and  has  to  make  a  decision  of  how  to  proceed.  If  he 
is  certain  that  the  reinforcements  will  arrive  on  time,  and  the  reinforcements  have  the 
right  mix  of  equipment  and  specialized  personnel,  he  will  proceed  with  Plan  B.  If  Plan  B 
is  earned  out  with  the  right  mix  of  equipment  and  personnel,  it  is  almost  certain  that  the 
rebels  will  be  contained  and  the  conflict  will  be  over  within  72  hours  with  minimal  loss 
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of  U.S.  life.  If  the  reinforcements  do  not  have  the  right  mix  of  personnel  and  equipment, 
and  the  commander  proceeds  with  Plan  B,  it  will  take  one  month  to  subdue  the  rebels  and 
may  cost  many  American  lives.  If  the  original  Plan  A  is  carried  out,  it  may  take  many 
months  to  subdue  the  rebels  but  loss  of  American  lives  will  be  minimal  and  the  stability 
of  the  Country  X  will  be  in  question.  The  reinforcements  deployed  three  hours  ago  and 
are  in  route  to  the  theater.  The  operational  commander  has  one  hour  to  make  his 
decision.  He  does  not  have  enough  time  to  communicate  with  the  reinforcement’s  base 
or  the  aircraft  carrying  them.  What  is  he  to  do? 

In  the  future,  the  operational  commander  should  have  at  his  disposal  the 
capability  to  get  to  the  GTN  web  site,  and  with  the  proper  clearance,  bring  up  a  map  of 
the  world.  He  can  find  out  where  the  reinforcements  originated  from  and  locate  the  three 
C-17s  carrying  them  on  the  map  and  know  the  exact  real-time  location  of  the  aircraft. 
With  a  click  of  the  mouse  or  a  voice  command,  a  diagram  of  a  C-17  and  its  contents  pop 
up.  Not  only  would  a  list  of  all  cargo  and  personnel  be  displayed,  the  diagram  of  the 
plane  will  show  where  in  the  plane  the  person  is  seated  or  piece  of  equipment  is  stowed. 
This  knowledge  can  prove  very  valuable  when  time  does  not  allow  the  luxury  of 
unloading  the  plane  and  sifting  through  the  cargo  to  find  a  specific  item.  Information 
about  the  individuals  on  the  plane  would  also  be  accessible.  Training  records, 
qualifications,  skills,  medical  information,  prior  experience,  etc.,  could  prove  valuable  to 
operational  leaders. 

In  our  scenario,  the  operational  commander  in  Country  X  finds  the  information  he 
needs  and  decides  that  the  proper  personnel  and  equipment  are  indeed  on  the  C-17s  and 
proceeds  with  planning  for  Plan  B  with  confidence  it  will  be  a  success. 
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The  TAV  capability  of  the  future  GTN  can  be  used  in  other  ways.  A  query  for  a 
critical  repair  item  could  be  done  and  the  location  of  all  such  items  that  are  in-transit 
could  be  found.  For  example,  a  query  for  part  Z  en  route  to  the  Mediterranean  could 
result  in  a  list  or  map  depicting  all  aircraft,  vehicles,  or  ships  carrying  that  part.  As  in  our 
previous  scenario,  diagrams  of  the  aircraft,  vehicles  or  ships  carrying  the  part  could  show 
the  physical  stow  location.  All  pertinent  information  concerning  the  part  could  be  shown 
such  as  document  numbers,  bills  of  lading  and  final  destinations.  Transportation 
schedules  change  very  rapidly.  Knowing  where  transportation  assets  are  at  any  one  time 
can  prove  very  valuable  in  such  a  dynamic  environment.  The  availability  of  satellite  and 
GPS  technology  provides  the  means  from  which  this  visibility  can  be  accomplished. 

For  obvious  reasons,  the  ability  to  change  the  routing  of  an  item  would  rest  with 
the  proper  authority.  This  change  of  routing  while  in-transit  could  be  accomplished  via 
the  GTN.  The  GTN  would  be  available  to  all  points  along  the  way  of  a  shipment.  At  any 
point,  the  part  could  be  pulled  (if  the  stow  location  makes  it  practicable)  and  re-routed  to 
a  different  destination. 

Because  technology  is  changing  at  such  a  rapid  pace,  it  is  not  feasible  to  know 
exactly  what  technologies  will  be  available  in  the  future  that  will  have  an  affect  on  the 
GTN.  For  this  reason,  the  GTN  does  not  have  a  future  end  state  and  is  not  expected  to. 
The  GTN  will  be  constantly  evolving  with  no  end  in  sight. 

F.  FUTURE  GTN  CONCERNS 

1.  Security 

In  order  for  the  GTN  to  provide  such  real-time  visibility  and  control  of  material, 
equipment,  and  personnel  to  operational  commanders,  a  large  amount  of  information  at 
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all  levels  of  classification  would  have  to  be  inputted  into  the  GTN.  With  so  much 
sensitive  information  feeding  into  the  system,  concerns  about  security  have  been  raised. 
In  order  for  the  GTN  to  reach  its  potential  as  an  effective  tool,  security  has  to  be  assured. 
Without  absolute  confidence  in  the  ability  of  the  GTN  to  process  sensitive  information 
without  compromise,  the  GTN  will  not  be  able  to  be  used  to  its  full  potential.  [Ref.  48] 

Threats  to  the  GTN  system  include  hackers,  ranging  from  the  amateur,  to  the 
sophisticated,  elite  hacker.  Motivation  for  hackers  can  be  curiosity,  feeding  their 
respective  egos,  or  financial  gain.  In  times  of  crisis,  foreign  countries  may  seek  to  try  to 
disrupt  our  deployment  plans,  logistical  requisitions,  and  resupply  and  sustainment 
transports.  [Ref.  48] 

If  these  countries  were  to  gain  access  to  sensitive  information  in  the  GTN,  they 
could  locate  and  target  our  forces,  reinforcements,  or  logistics  pipelines.  By  doing  so, 
military  operations  would  be  disrupted  severely  affecting  the  course  of  a  war. 

There  is  also  a  potential  threat  from  terrorists.  Information  from  the  GTN  could 
be  used  to  obtain  information  on  personnel,  travel  itineraries,  and  movement  plans. 
Malicious  code  could  be  launched  by  internal  or  external  means  and  may  be  designed  to 
stay  dormant  and  wait  for  a  specific  time  or  until  orders  are  given  before  damaging  the 
GTN  and  related  systems.  [Ref.  48] 

Although  hackers,  foreign  countries,  and  terrorists  pose  a  significant  threat,  the 
biggest  threat  is  from  insiders  who  have  authorized  access  to  our  systems.  These  insiders 
already  have  access  to  information  and  therefore  can  bypass  most  security  mechanisms 
designed  to  keep  the  unauthorized  intruder  from  the  outside  from  gaining  access.  [Ref. 
48] 
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The  GTN  consists  of  an  Unclassified  GTN  network  and  a  Classified  network.  By 
its  very  nature  the  classified  network  is  easier  to  control  access  to  and  the  threat  of 
security  breaches  from  outside  intruders  are  less  than  that  of  the  Unclassified  network. 
Currently,  the  unclassified  GTN  system  web  servers  and  databases  are  protected  by 
actively  monitoring  and  employing  a  set  of  industry  standard  security  processes  and  state 
of  the  art  hardware  and  software  tools.  These  processes  and  tools  are  blended  into  a 
defense  in  depth  architecture.  [Ref.  48] 

The  security  process  includes  Auditing,  Access  Control,  Encryption,  and 
Configuration  Management.  Auditing  identifies  who  has  accessed  or  attempted  to  access 
the  system,  detects  unauthorized  changes  to  the  GTN  system  security  settings  and 
enforces  security  policy.  Access  Control  allows  only  authorized  connections  and 
Encryption  allows  secure  connections  from  the  user’s  desktop  to  GTN  web  servers  and 
secure  database  data  replication  between  databases.  Configuration  Management 
physically  protects  and  identifies  all  systems  on  the  network  identifies  protocols  and 
services  they  use  their  vulnerabilities,  and  controls  the  impact  of  hardware  and  software 
updates  on  security  of  the  network.  [Ref.  48] 

Each  of  these  security  processes  are  supported  by  one  of  the  following  security 
tools:  Crack,  Tripwire,  COPS  Checkpoint  Firewall  I,  NIDS  VPN,  C2  Guard,  Proxy 
Server,  Netscape  Certificate  Server,  SSL,  SSH,  TKIned,  Fstrobe,  MITRE,  Enhanced 
SATAN,  Internet  Security  Scanner,  Webserver  and  Browser.  These  tools  are  integrated 
into  an  architecture  that  provides  three  levels  of  protection  for  the  system.  [Ref.  48] 

Level  1  is  to  prevent  the  USTRANSCOM  network  infrastructure  form  being  used 
as  a  platform  to  attack  the  GTN  network.  Level  2  is  GTN’s  own  network  with  redundant 
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and  independent  protection.  Level  3  provides  monitoring  and  oversight  of  the  previous 
two  levels.  [Ref.  48] 

As  the  GTN  uses  more  web  technology,  the  protection  of  the  GTN’s  web  servers 
is  critical.  Protection  of  the  web  servers  is  accomplished  by  setting  them  up  on  their  own 
network  segments  to  minimize  potential  collateral  damage. 

The  challenges  for  keeping  the  GTN  secure  for  the  future  involves  feeder  systems 
and  the  classified  GTN.  Because  the  GTN  relies  heavily  on  the  interconnectivity  of  a 
number  of  networks,  the  security  of  the  networks  is  key  to  a  secure  system.  If  a  feeder 
system  is  compromised,  the  possibility  exists  that  the  active  GTN  system  could  be 
compromised  and  corruption  of  data  is  possible.  The  most  effective  weapon  against 
feeder  system  security  breaches  is  educating  the  feeder  system  supervisors.  Other  way  to 
ensure  that  feeder  systems  are  not  compromised  is  the  use  of  services  and  agencies  in 
acquiring  protective  hardware,  software,  and  expertise.  The  implementation  of 
Information  Architecture/Intemet  Protocol  (IA/IP),  which  uses  encryption  technologies 
for  information  passing  over  the  Internet,  will  strengthen  the  security  of  the  GTN  feeder 
systems.  (GTN  Security  Brief,  Jan  00)  The  security  architecture  has  been  tested  and 
evaluated  by  several  DOD  organizations  including  DISA,  NSA,  ER,  AFTWC,  JC2WC. 
These  organizations  have  done  daily  connection  and  probe  attempts  and  has  found  the 
unclassified  GTN  secure.  [Ref.  48] 

Security  is  improving  against  the  threat  from  outsiders,  and  as  a  result,  the  shift  is 
moving  from  instituting  attacks  from  the  outside  to  instituting  attacks  from  the  inside. 
Some  of  the  most  harmful  security  breaches  in  the  DOD  have  been  from  people  working 
inside  the  U.S.  government.  The  security  measures  that  are  present  in  the  unclassified 
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network  are  required  to  protect  the  classified  GTN.  Access  control  and  audit  capability 
are  needed  to  prevent  insider  attacks  to  the  system  which  have  the  potential  to  be  just  as 
harmful  is  not  more  harmful  than  attacks  from  the  outside.  [Ref.  48] 

If  the  GTN  is  to  remain  safe  from  intrusion  in  the  future,  the  GTN  security 
architecture  will  have  to  be  continually  improved.  The  threat  is  an  evolving  one  and 
those  attempting  to  infiltrate  our  systems  will  continue  to  exploit  new  technologies. 
Whatever  form  the  GTN  takes  in  the  future,  preventing  security  attacks  will  require  the 
utmost  vigilance. 

2.  Formats 

The  systems  that  feed  into  the  GTN  are  usually  in  ANSIX12  format,  since  that  is 
the  format  that  is  the  standard  in  the  U.S.  Any  feeder  systems  from  outside  the  U.S.  are 
usually  in  the  international  standard  format,  EDIFACT.  The  GTN  uses  its  own  flat 
format  and  data  from  feeder  systems  must  be  translated  into  this  flat  format  for  use  by  the 
GTN.  Because  of  the  labor  involved  with  translating  each  feeder  system’s  data.  Value 
Added  Networks  (VAN)  are  used  to  translate  data  from  the  feeder  systems  and  the  GTN. 
Just  recently,  a  contract  was  awarded  to  a  VAN  to  translate  all  data  from  all  formats  and 
feeder  systems.  Using  one  VAN  is  more  efficient  than  dealing  with  a  large  number 
format  versions.  [  Ref.  49] 

Since  there  are  essentially  two  standard  formats,  ANSIX12  and  EDIFACT,  why 
doesn’t  the  GTN  use  one  of  these  formats?  Although  ANSIX12  and  EDIFACT  are  the 
standards  for  data  transmission,  there  are  a  number  of  different  versions  of  each  standard 
currently  being  used  by  feeder  systems.  Even  if  the  GTN  used  one  of  these  standard 
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formats,  translation  would  still  have  to  be  done  to  match  up  the  feeder  systems  with  the 
version  that  the  GTN  was  using.  [  Ref.  49] 

Many  of  the  systems  that  feed  into  the  GTN  are  from  small  companies  who  do  not 
have  the  resources  to  invest  in  updated  EDI  systems.  Keeping  up  with  the  most  updated 
standard  version  would  be  cost  prohibitive  for  these  companies.  Using  a  standard  format 
that  is  cost  effective  and  easy  to  use  that  would  satisfy  the  needs  of  both  the  feeder 
systems  and  the  GTN  would  be  ideal.  This  would  make  it  unnecessary  to  use  a  VAN  to 
translate  data  for  use  in  the  GTN.  Data  could  be  transmitted  from  each  feeder  system 
directly  into  the  GTN  without  the  delay  and  cost  of  translating  it. 

There  is  an  emerging  data  format  that  holds  promise.  Extensible  Markup 
Language  (XML)  is  a  fairly  new  format  that  is  simpler  to  use  and  is  more  capable  than 
HTML.  In  fact,  using  XML  may  be  the  answer  to  the  problem  of  different  formats 
needing  to  be  translated  to  flat  data  files  for  use  in  the  GTN.  XML  may  make  it  possible 
for  small  feeder  systems  to  feed  the  GTN  without  the  use  of  a  VAN.  [  Ref.  49] 

G.  GTN  FUTURE  TECHNOLOGIES 

1.  Intelligent  Transportation  Systems  (ITS) 

The  definition  of  ITS  is:  Any  project  that  (in  whole  or  in  part)  involves  the 
application  of  electronics,  communications,  or  information  processing  used  singly  or  in 
combination  to  improve  the  efficiency  or  safety  of  a  surface  transportation  system. 
Although  this  definition  deals  with  surface  transportation,  the  definition  may  be  altered  to 
include  any  form  of  transportation.  [Ref.  50] 

The  GTN  can  benefit  from  the  developments  in  ITS  and  must  stay  abreast  of 
current  and  future  developments  in  the  ITS  arena  to  stay  on  the  cutting  edge  of 
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transportation  technology.  ITS  technology  covers  a  wide  range  of  areas  from  automatic 
cars  and  highways  to  real  time  mapping  and  traffic  status.  Most  of  the  developments  in 
ITS  will  benefit  DOD  transportation  as  a  result  of  the  commercial  sector  universally 
adopting  new  technologies  that  will  affect  general  transportation.  An  example  of  such  a 
technology  that  will  be  universally  adopted  is  automatic  tollbooths.  As  tollbooths 
become  automated,  DOD  transportation  will  benefit  in  concert  with  the  general  public 
from  the  cost  and  timesaving  brought  about  by  such  technology.  [Ref.  50] 

There  are,  however,  a  few  ITS  technologies  that  can  be  exploited  by  the  DTS 
without  having  to  wait  for  the  technology  to  take  hold  in  the  commercial  sector  first.  One 
of  these  technologies  concerns  automatic  route  optimization.  When  large  movements  of 
troops  or  equipment  are  planned,  whether  for  training  or  for  actual  deployments,  data 
concerning  the  surface  transportation  routes  can  be  available  automatically.  This  data 
can  be  used  to  plan  the  route  that  will  allow  the  most  expeditious  movement  from  the 
point  of  departure  to  the  destination.  Information  concerning  road  conditions,  ongoing 
road/infrastructure  construction,  highway,  bridge,  and  tunnel  weight  and  height 
limitations,  hazardous  material  limitations  along  a  route,  planned  traffic  along  a  route  for 
specific  time  of  day  or  the  week,  weather  conditions  along  the  route,  and  any  delays  due 
to  emergencies  or  accidents  is  available  using  ITS  technology.  This  information,  in 
whole  or  in  part,  is  currently  available  in  certain  metropolitan  areas  of  the  world, 
including  many  areas  in  the  United  States.  Including  this  information  in  the  GTN  could 
provide  significant  advantages  to  planning  and  executing  force  movements. 

The  following  scenario  is  an  example  of  how  such  technologies  could  be  used  as 
part  of  the  GTN.  All  information  concerning  the  route  of  movement  mentioned  above  is 
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fed  into  the  GTN.  In  the  event  of  contingencies,  it  will  be  necessary  to  execute  a  large 
movement  of  deploying  troops  from  Fort  Hood,  Texas  along  surface  transportation  routes 
to  embark  on  ships  waiting  in  port  New  Orleans,  Louisiana.  The  planned  route  is  entered 
into  the  GTN.  The  system  can  be  set  up  to  provide  constant  updates  of  route  conditions 
on  a  monthly,  weekly,  daily,  or  hourly  basis.  When  the  order  comes  to  commence 
movement,  the  system  could  provide  the  best  route  to  take,  what  time  of  day  is  optimum, 
and  when  to  stagger,  if  needed,  vehicle  movements  so  as  to  prevent  congestion  at  the 
departure  or  arrival  destinations. 

By  using  this  information,  departure  from  base  to  embarking  on  the  vessels  can  be 
executed  efficiently  with  the  minimum  number  of  delays  or  routing  problems  and  may 
save  days  on  getting  troops  and  equipment  where  they  should  be  when  they  should  be. 

2.  Satellites  and  Related  Automated  Information  Technology  (AIT) 

Satellites  and  related  AIT  could  theoretically  play  a  central  role  in  the  future 
evolution  of  the  GTN,  particularly  in  the  area  of  TAV.  To  set  up  this  analysis,  it  is 
necessary  to  first  examine  some  of  the  principles  of  AIT  devices.  Next,  the  authors  will 
attempt  to  portray  their  future  integration  with  satellite  tracking  systems  and  the 
relationship  to  the  GTN/feeder  systems. 

AIT 

ATT  encompasses  a  variety  of  read  and  write  data  storage  technologies  that 
capture  asset  identification  information.  Those  technologies  include  bar  codes,  magnetic 
stripes,  integrated  circuit  cards,  optical  memory  cards,  and  radio  frequency  identification 
tags.  ATT  also  includes  the  hardware  and  software  to  create  the  storage  devices,  read  the 
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information  stored  on  them,  and  integrate  that  information  with  other  logistics  data.  It 
also  includes  the  use  of  satellites  to  track  and  redirect  shipments.  [Ref  4:p.  iii] 

AIT  devices  offer  a  wide  range  of  data  storage  capacities  from  a  few  characters  to 
thousands  of  bytes.  The  information  on  each  device  can  range,  for  example,  from  a  single 
part  number  to  a  self-contained  database.  The  devices  can  be  interrogated  using  a  variety 
of  means,  including  contact,  laser,  or  radio  frequency,  with  the  information  obtained  from 
those  interrogations  provided  electronically  to  automated  information  systems  (AISs)  that 
support  DOD’s  logistics  operations.  [Ref  4:pp.  iii-iv] 

Although  not  truly  an  AIT  device,  RF  data  communications  (RFDC)  also  deserve 
mention  because  of  their  role  in  sending  real  time  data  to  AISs.  In  applications  that 
require  a  real-time  update  to  a  database,  using  RFDC  is  preferred  to  sending  data  as  a 
batch  via  a  modem  or  a  direct-connect  download.  RFDC  is  usually  used  to  provide  a 
real-time  link  between  an  AIS  host  computer  and  a  hand-held  terminal.  [Ref.  38:p.  2.2] 
Railroads  have  used  RFID  technology  since  the  late  1980s  for  tracking  and 
equipment  management.  [Ref  51]  Within  the  military,  this  technology  is  used  to  identify, 
categorize,  and  locate  people  and  materiel  automatically  within  relatively  short  distances 
(a  few  inches  to  300  feet).  RFID  capabilities,  particularly  those  provided  by  active  RF 
tags,  are  beneficial  when  a  user  needs  to  locate  and  redirect  individual  containers  or  have 
stand-off,  in-the-box  visibility  of  container  contents.  RFID  may  also  be  used  to  support  a 
customer  in  a  forward  area  with  an  inadequate  systems  or  communications  infrastructure. 
The  active  RFID  capability  offers  significant  capabilities  for  yard  management,  port 
operations,  and  in-transit  visibility  (ITV)  that  cannot  be  provided  by  passive  RF  tags. 

[Ref.  38:p.  2.3] 
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Active  and  Passive  RF  Tags 

RFID  labels  are  known  as  tags  or  transponders.  They  contain  information  that  can 
range  from  a  permanent  ID  number  programmed  into  the  tag  by  the  manufacturer  to  an 
extensive  memory  that  can  be  programmed  by  a  controller  using  RF  energy.  The  controller 
is  usually  referred  to  as  a  reader  or  an  interrogator.  [Ref.  38:p.  2.4] 

An  interrogator  and  a  tag  use  RF  energy  to  communicate  with  each  other.  The 
interrogator  sends  a  RF  signal  that  “wakes  up”  the  tag,  and  the  tag  transmits  information 
to  the  interrogator.  In  addition  to  reading  the  tag,  the  interrogator  can  write  new 
information  on  the  tag.  This  permits  a  user  to  alter  the  tag’s  information  within  the 
effective  range.  Interrogators  can  be  networked  to  provide  extensive  coverage  for  a 
system.  [Ref.  38:p.  2.5] 

Passive  RF  tags  operate  similarly  to  active  RFID  tags  except  the  data  capability  of 
passive  tags  is  significantly  limited.  Additionally,  interrogation  of  these  tags  is  generally 
constrained  to  line-of-sight.  [Ref.  38:p.  2.5] 

Satellite  Tracking  Systems 

A  satellite-tracking  system  provides  the  ability  to  track  the  exact  location  of 
vehicles  and  convoys.  The  latitude  and  longitude  locations  of  trucks,  trains,  and  other 
transportation  assets  equipped  with  a  transceiver  are  transmitted  periodically  via  a 
satellite  to  a  ground  station.  Some  systems  also  provide  two-way  communications 
between  a  vehicle  operator  and  a  ground  station.  [Ref.  38:p.  2.5] 

Satellite  tracking  uses  a  cellular  or  satellite-based  transmitter  or  transceiver  unit  to 
communicate  positional  information,  encoded  and  text  messages  from  in-transit 
conveyances  to  the  ground  station.  Transceiver-based  technologies  also  permit 
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communications  from  a  ground  station  to  the  in-transit  conveyance.  A  user  can  compose, 
transmit,  and  receive  messages  with  very  small  hand-held  devices  or  units  integrated  with 
computers  anywhere  in  the  world.  The  greatest  use  of  this  technology  is  in  the 
commercial  motor  carrier  industry.  However,  this  capability  is  easily  adapted  to  rail,  bus, 
barge,  military  organic,  and  other  surface  modes.  Additionally,  the  emerging  low-earth 
orbit  (LEO)  satellite  constellations  will  facilitate  tracking  international  multimodal 
shipments.  [Ref.  38:p.  2.5] 

The  following  description  provides  a  clarification  of  how  a  satellite-tracking 
system  may  currently  operate  in  DOD.  A  typical  system  has  five  components— a 
subscriber  unit,  satellite,  earth  station,  network  control  center  (NCC),  and  logistics 
managers.  A  subscriber  unit  is  installed  on  the  conveyance  being  tracked.  The  unit 
exchanges  information  with  an  earth  station  via  satellite.  The  earth  station  is  connected  to 
a  NCC  that  stores  information  in  electronic  mailboxes.  Logistics  managers  access  their 
mailboxes  to  receive  information  from  subscriber  units  and  return  information  to  them. 
[Ref.  38:p.  2.6] 

Satellite  tracking  to  facilitate  in-transit  visibility  has  shown  substantial  benefits, 
but  at  the  present  is  somewhat  limited.  Currently,  the  most  effective  use  is  for  tracking 
and  communicating  with  vehicles  and  other  transportation  assets  rather  than  individual 
containers.  The  limitation  lies  in  the  need  for  a  subscriber  unit  and  an  operator  for  that 
unit.  [Ref.  38:p.  2.6]  Presently,  the  technology  has  not  developed  sufficiently  to  offer  a 
stand-alone  “tag”  that  can  be  interrogated  by  a  satellite  and  simultaneously  be  within  the 
budget  of  the  military.  Although,  there  have  been  many  advances  which  will  conceivably 
lower  the  cost  of  this  technology  (particularly  with  the  use  of  low-earth  orbit  satellites). 
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The  John  A.  Volpe  National  Transportation  Systems  Center  (Volpe  Center), 
located  in  Cambridge,  Massachusetts,  has  extensive  expertise  in  satellite-based 
radionavigation  systems.  The  Volpe  Center  is  a  unique  Federal  Government  organization 
that  is  actually  funded  by  client  agencies,  both  public  and  private,  to  address  specific 
problems  such  as  the  one  outlined  above.  [Ref  52]  Their  research,  combined  with  private 
enterprise,  has  the  potential  to  yield  significant  progress  for  satellite  tracking. 

Satellites  and  the  GTN 

As  satellite  and  information  technologies  develop  further,  the  authors  believe  that 
the  possibility  to  exploit  their  combined  benefits  may  hold  significant  potential  to 
substantially  improve  and  increase  the  capabilities  of  the  GTN.  Additionally,  as  the  cost 
of  these  technologies  continues  to  decrease  and  their  capabilities  increase,  many  new 
possibilities  are  afforded  to  DOD. 

To  offer  a  theoretical  operational  concept,  the  following  is  provided.  The 
concept  proposes  the  use  of  a  standard,  miniaturized,  reusable,  active  tag  as  the  sole 
device  for  use  in  information  coding  (or  capture  of  asset  identification  information)  to  be 
placed  on  virtually  any  item  or  person  to  be  tracked.  The  use  of  these  tags  could  be 
increased  and  expanded  to  other  modes  of  travel.  Additionally,  it  may  be  possible  to 
eliminate  many  of  the  current  information  systems,  hardware  and  software  (and 
associated  integration  difficulties).  This  would  be  possible  through  the  use  of  tags  that 
continually  feed  positional  and/or  logistics  data  directly  to  the  satellites  or  are 
interrogated  directly  by  the  satellites.  In  either  case,  the  satellites  would  capture  that  data 
and  forward  it  to  a  centralized  repository  (the  GTN).  That  data  would  be  immediately  (or 
within  seconds)  available  to  authorized  users,  commercial  and/or  military. 
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The  entire  tracking  system,  including  the  satellite  (or  the  usage  of)  and  hardware 
components  (tags,  tagging  system,  etc. . could  be  under  the  responsibility  of  a  separate 
directorate  formed  or  contracted  by  USTRANSCOM.  Membership  would  be  comprised 
of  the  appropriate  technical  staff  and  representatives  from  all  of  the  various  initiatives 
currently  being  undertaken.  In  addition,  representatives  from  DLA  could  augment  the 
directorate  staff.  They  would  be  needed  to  ensure  that  inventory  policies  and  initiatives 
are  also  incorporated  in  conjunction  with  the  directorate’s  efforts. 

All  associated  software  and  information  systems  needed  would  be  controlled 
under  that  centralized  directorate.  Further,  a  single  information  system  and  software 
could  be  adopted  under  this  concept  (once  again,  eliminating  many  of  the  associated 
integration  problems).  The  service  would  essentially  be  offered  through  the  Internet  for 
both  military  and  commercial  customers.  Correspondingly,  there  would  be  a  fee  for 
those  services  (most  likely  dependent  upon  usage,  type  of  services  required,  hardware 
requirements,  or  some  combination  thereof).  Thus,  the  fees,  in  combination  with 
elimination  of  numerous  redundant  feeder  systems  and  their  infrastructures,  may  offer  a 
cost-effective  alternative  to  the  current  system. 

Another  possible  advantage  of  the  system  is  that  it  may  hold  the  potential  to 
become  the  industry  standard.  As  the  USTRANSCOM  survey  indicated,  several  shippers 
would  be  willing  to  use  only  the  GTN  if  the  information  were  as  accurate  as  the  carriers’ 
systems.  With  the  elimination  of  individual  intermediate  feeder  systems  (brought  about 
through  centralization)  and  much  of  the  manual  intervention  eliminated  (tag  data 
transmitted  directly  to  the  satellite  and  directly  to  the  GTN),  data  accuracy  could 
substantially  be  increased.  Over  time,  the  improvements  should  lead  to  a  robust 
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capability  that  could  conceivably  rival  commercial  carrier  systems.  In  the  future,  it  may 
prove  more  cost  effective  for  the  commercial  carriers  to  utilize  the  GTN  services 
provided  by  the  directorate.  A  standardized  system  among  both  the  military  and 
commercial  sectors  offers  monumental  advantages  and  the  opportunity  for  further 
evolution. 

H.  CHAPTER  SUMMARY 

The  future  holds  significant  potential  to  increase  and  enhance  the  capabilities  of 
the  GTN.  In  addition,  the  current  philosophy  at  USTRANSCOM  is  that  there  is  no 
definite  end-state  in  the  evolution,  of  GTN.  As  future  technologies  become  available,  the 
plan  is  to  exploit  them  to  the  fullest  extent  possible  to  improve  the  GTN  in  support  of  its 
customers.  The  goal  is  continual  improvement. 

There  are  a  number  of  future  concerns  that  need  to  be  continually  addressed. 
These  concerns  include  security  and  data  formats.  In  order  for  the  GTN  to  be  utilized  to 
its  fullest  extent,  especially  when  processing  sensitive  information,  security  needs  to  be 
guaranteed.  Data  formats  continue  to  be  problematic.  Currently  a  VAN  is  used  to 
integrate  the  large  number  of  differing  formats  and  alternate  solutions  are  being 
researched. 

As  suggested  previously,  the  possibility  of  capitalizing  upon  new  technologies  is 
virtually  limitless.  The  authors  proposed  several  operational  scenarios  and  suggested 
additional  technologies  that  may  offer  increased  capabilities  for  the  GTN. 
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V.  SUMMARY,  CONCLUSIONS,  AND  RECOMMENDATIONS 
A.  SUMMARY 

This  research  outlined  the  changes  that  have  occurred  within  Global 
Transportation  Network  (GTN)/In  Transit  Visibility  (ITV)  feeder  systems  and  the 
subsequent  ITV  they  provide  by  comparing  the  current  position  to  the  past  and  examining 
future  trends. 

USTRANSCOM  was  established  as  the  single  manager  for  transportation  in  both 
peace  and  war.  As  part  of  its  mission,  it  created  a  transportation  management  system  that 
would  provide  ITV  to  all  DOD  transportation  users  throughout  the  world.  Shortly  after 
creating  the  GTN  concept,  the  feasibility  of  providing  global  ITV  was  demonstrated 
through  “proof-of-concept”  prototypes.  Earlier  success  with  “proof  of  concept”  GTN 
prototypes  set  the  stage  for  developing  operational  prototypes. 

The  capabilities  of  the  operational  prototypes  increased  steadily  and 
USTRANSCOM  implemented  a  number  of  initiatives  to  address  user  needs  and  gain  full 
advantage  of  evolving  technology.  Pull  systems  gave  way  to  push  systems.  Surface,  air, 
and  sea  capabilities  were  added.  Client-server  architectures  were  replaced  with  Web- 
based  technology.  A  number  of  key  management  and  infrastructure  changes  were  also 
implemented.  In  addition,  numerous  initiatives  were  implemented  that  aided  in 
development.  These  initiatives  included  data  standardization,  migration  strategies,  ITV, 
JTAV,  DTEDI,  ATT,  EB/CEDI,  and  life  cycle  costs/benefits  analyses. 

The  contract  for  the  GTN  production  system  was  awarded  in  1995.  New 
capabilities  and  functionalities  were  continually  enhanced  throughout  the  1990s. 
Questions  continually  arose  concerning  the  future  of  the  GTN. 
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The  future  holds  significant  potential  to  increase  and  enhance  GTN  capabilities. 
In  addition,  the  current  philosophy  at  USTRANSCOM  maintains  that  there  is  no  definite 
end-state  in  GTN  evolution.  As  future  technologies  become  available,  the  plan  is  to 
exploit  them  to  the  fullest  extent  possible  to  improve  the  GTN  and  support  its  customers. 
The  goal  is  continual  improvement. 

There  are  a  number  of  future  concerns,  including  security  and  data  formats  that 
need  to  be  continually  addressed,  but  the  possibility  of  capitalizing  upon  new 
technologies  is  virtually  limitless. 

B.  CONCLUSIONS  AND  RECOMMENDATIONS 

1.  Conclusion:  Satellite  technology  possesses  the  potential  to 
substantially  improve  and  increase  GTN  capabilities,  particularly  in  regard 
to  TAV. 

Satellite  technology  offers  the  possibility  of  a  centralized  technology  that  may 
eventually  replace  many  of  the  current  feeder  systems  and  associated  infrastructure.  Data 
could  theoretically  be  captured  and  forwarded  to  a  centralized  repository  (the  GTN)  and 
be  available  virtually  real-time  for  authorized  users. 

Recommendation:  USTRANSCOM  should  evaluate  the  feasibility  of 
establishing  a  separate  directorate  for  satellite  technology  and  incorporating 
satellite-collected  data  into  the  GTN. 

Satellite  technology  has  been  used  successfully  to  facilitate  TAV,  feeding 
information  to  the  GTN.  However,  its  use  has  been  somewhat  limited.  Currently,  the 
most  effective  use  has  been  tracking  and  communicating  with  transportation  assets.  A 
separate  directorate  would  be  required  to  fully  evaluate,  develop,  and  implement  the 
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technology  and  to  exploit  the  potential  capabilities  to  include  all  transportation  modes, 
containers,  assets,  and  personnel. 

Membership  of  the  directorate  should  include  representation  from  the  appropriate 
technical  disciplines,  USTRANSCOM  initiatives  currently  being  undertaken,  and  from 
DLA.  In  conjunction  with  many  of  the  current  initiatives,  a  single  information  system, 
hardware  and  software  could  potentially  be  adopted  under  the  centralized  concept.  This 
would  provide  a  significant  impetus  to  integration  efforts. 

Recommendation:  USTRANSCOM  should  evaluate  the  feasibility  of 
offering  the  services  available,  as  a  result  of  satellite  technology 
(incorporated  through  the  GTN),  through  the  Internet 
The  services  available  should  be  robust,  accurate,  and  timely.  The  possible 
benefits  are  virtually  limitless  at  all  levels  in  the  military  and  commercial  sectors. 
Authorized  access  through  the  Internet  offers  the  potential  to  assess  fees  and  defray 
associated  costs.  Overall,  assessing  fees  and  eliminating  many  of  the  current  systems  and 
infrastructures  could  make  this  technology  an  extremely  viable  alternative. 

2.  Conclusion:  The  large  variety  of  devices,  tags  and  labels  used  for 
information  coding  and  capturing  asset  identifi cation  information  causes 
significant  integration  difficulties. 

Currently,  a  number  of  devices  or  technologies  are  being  used  to  capture  and  store 
asset  identification  information.  This  fact,  in  itself,  generates  a  number  of  integration 
difficulties,  particularly  across  the  Services  and  in  interaction  with  the  commercial  sector. 
Consequently,  it  also  can  result  in  problems  with  TAV. 
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Recommendation:  USTRANSCOM  should  investigate  adopting  a 
standard,  miniaturized,  reusable,  active  tag  technology  to  replace  the 
number  of  current  technologies  being  used  for  AIT. 

As  alluded  to  in  the  introduction,  miniaturized  computers  have  been  developed 
that  possess  more  capability  than  most  current  desktop  PCs.  They  contain  CPU  chips 
that  are  smaller  in  size  than  a  postage  stamp.  Conceivably,  a  chip  used  only  to  capture 
asset  identification  information  and  perform  minimal  processing  could  be  even  smaller 
and  less  expensive.  As  technology  evolves,  it  may  be  possible  and  cost  effective  to  use 
such  a  chip  to  facilitate  TAV  and  replace  the  devices  currently  in  use.  In  effect,  a  single 
technology  that  would  facilitate  AIT  standardization  and  integration  with  standard  use 
among  all  transportation  modes.  In  addition,  that  technology  could  continually  be 
more  cost  effective  through  widespread  adoption  and  mass  production. 

Recommendation:  Incorporate  the  “standard”  tag  technology  with  satellite 
technology  to  facilitate  TAV. 

At  present,  the  capability  has  been  developed  for  a  “tag”  to  communicate  directly 
with  one  or  more  satellites  or  for  the  satelhte(s)  to  interrogate  the  tag  and  obtain  its 
information.  These  two  technologies  seem  to  be  well  suited  to  use  in  combination.  A 
single  ATT  device  would  theoretically  make  the  satellite  technology  referenced  above 
significantly  easier  to  implement  for  TAV. 

3.  Conclusion:  The  GTN  must  be  kept  up  to  date  with  the  latest 
security  software  and  security  procedures  to  ensure  vital  data  are  not 
compromised  as  the  GTN  improves  TAV  capabilities. 
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The  GTN  has  the  potential  to  become  the  one  source  for  logistics  data  to  both 
operational  commanders  and  strategic  planners.  Coupled  with  this  potential  is  the 
increasing  possibility  of  damage  due  to  compromised  data. 

Recommendation:  Continue  vigilantly  monitoring  the  GTN  and  its  feeder 
systems  for  possible  compromise  due  to  hackers  and  terrorist  activity. 
Maintain  training  efforts  to  keep  users  current  on  the  latest  methods  for 
preventing  security  breaches.  Closely  follow  the  latest  security  technologies 
in  both  government  and  the  private  sector,  and  implement  the  most 
promising  technologies  into  the  GTN. 

4.  Conclusion:  The  GTN  is  not  taking  full  advantage  of  Intelligent 
Transportation  Systems  (ITS)  systems  and  current  technologies  for  surface 
transportation. 

ITS  has  the  potential  for  providing  real-time  information  on  surface 
transportation.  Information  available  by  using  ITS  includes,  but  is  not  limited  to:  real¬ 
time  traffic  speed  and  congestion  information;  information  on  route  construction;  weight 
and  height  limitations;  data  on  average  travel  times  dependent  on  time  of  day;  and 
automatic  toll,  weigh,  and  border  crossing  stations. 

Recommendation:  USTRANSCOM  should  set  up  a  liaison  with  the  U.  S. 
Department  of  Transportation  concerning  ITS  so  that  the  GTN  can  exploit 
information  available  through  various  ITS  technologies. 

C.  FURTHER  RESEARCH  AREAS 

1.  What  is  the  estimated  cost  of  incorporating  satellite  technologies  into  the 
GTN? 
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2.  If  a  satellite  technology  directorate  were  established  by  USTRANSCOM,  how 
would  the  organizational  structure  be  determined? 

3.  What  is  the  most  efficient  and  useful  format  for  transferring  data  between 
feeder  systems  and  the  GTN? 

4.  How  could  the  GTN  benefit  from,  and  what  is  the  estimated  cost  of, 
exploiting  emerging  Intelligent  Transportation  technologies  in  the  future? 

5.  Develop  a  costfoenefit  analysis  of  adopting  a  single,  standard  tag  or  chip 
technology  to  replace  the  number  of  current  technologies  being  used  in  ATT. 
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APPENDIX  A 


Current  Sources  of  Information 

Automated  Air  Load  Planning  System  (AALPS) 

GTN  will  have  the  capability  to  accept  load  plans  and  stow  plans  developed  by 
applications  such  as  Automated  Air  Load  Planning  System  (AALPS).  Information 
developed  in  these  applications  will  be  passed  to  GTN  through  established  interfaces 
such  as  GDSS,  TC  AIMS  II,  and  WPS.  AALPS  assists  users  in  loading  Air  Force  and 
commercial  transport  aircraft.  It  takes  data  input  of  personnel  to  establish  gross  load 
planning  information,  and  it  produces  fully  certified  load  plans  for  single  mission, 
brigade  sized  or  multiple  division  sized  airlift  deployment  requirements. 

Air  Carrier  Analysis  Support  System  (AC AS) 

ACAS  provides  automated  support  for  trend  analysis  of  the  safety  posture  of 
commercial  air  earners  providing  airlift  to  DOD.  The  mission  of  ACAS  is  to  provide  the 
DOD  Air  Carrier  Survey  and  Analysis  Office  an  integrated  system  for  trend  analysis, 
scheduling,  and  mission  support  requirements  IAW  Public  Law  99-661  and  DOD 
Directive  4500.53. 

Asset  Management  System  (AMS-) 

AMS  is  a  transportation  management  system  that  automates  the  management  of 
the  DoD  Interchange  Freight  Car  Fleet  and  the  Common  User  Container  Fleet.  It  will 
provide  greater  asset  visibility;  enhance  utilization,  and  improve  maintenance,  tracking 
and  rail  revenue  auditing. 

Command  and  Control  Information  Processing  System  (C2IPS) 

C2IPS  provides  centralized  “electronic  grease  board”  capability  for  each 
functional  area  in  airlift  wings,  air  refueling  wings,  airlift  squadrons,  and  air  refueling 
squadrons,  and  mobility  forces.  C2IPS  extends  automated  command  and  control 
capabilities  to  fixed  and  deployable  field  units,  including  ANG  and  Air  Reserve 

Command,  while  interfacing  with  other  C2  systems  to  share  critical  tanker  and 
airlift/aircrew  information.  The  mission  of  C2IPS  is  to  support  wing-level  airlift  and 
tanker  execution,  tracking,  and  analysis  during  peacetime,  crisis/contingency,  and  war. 

Consolidated  Air  Mobility  Planning  System  (CAMPS) 

CAMPS  is  a  migration  system  for  ADANS  and  currently  under  development.  It 
supports  peacetime,  crisis/contingency,  and  wartime  mobility  planning,  scheduling,  and 
analysis  for  air  transportation  assets.  CAMPS  primarily  supports  AMC  military  airlift, 
aerial  refueling,  and  commercial  aircraft  missions.  CAMPS  and  the  Global  Decision 
Support  System  (GDSS)  do  planning  and  scheduling  for  transportation  airlift  missions, 
thus  providing  planning  visibility  from  origination  of  the  mission  requirement  to  the 
actual  scheduling.  CAMPS  will  provide  GTN  with  channel  requirements  data,  DD  Form 
1249  SAAM  Airlift  Requests,  and  air  refueling  quarterly  planning  schedules. 
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Canadian  Transportation  Automated  Control  system  tCanTRACSl 

CanTRACS  is  a  system  that  automates  transportation  and  contract  administration 
processing  and  generates  documents  for  shipments  from  DOD  contractors  throughout 
Canada.  The  mission  of  CanTRACS  is  to  provide  DCMC  America  and  contractors  with 
>  a  system  for  the  procurement  of  commercial  freight  transportation  services  in  peace  and 
war.  It  also  provides  DCMC  Americas  with  a  contract  database  including  contract 
requirements  for  transportation  including  item  descriptions,  terms  and  conditions. 

CONUS  Freight  Management  (CFMt 

CFM  is  MTMC’s  unclassified  system  providing  automated  support  to  TOs  and 
MOs  for  transportation  processing  and  planning.  CFM  receives  EDI  transactions  from 
transportation  systems.  CFM  will  provide  movement  status  (Implementation  Convention 
858)  on  cargo  moved  within  CONUS. 

Defense  Transportation  Tracking  System  (PITS’! 

DTTS  is  operated  by  the  Naval  Supply  Systems  Command/Navy  Material 
Transportation  Office  for  DoD.  DTTS  is  the  DoD  unclassified  system  for  near  real-time 
tracking  of  Class  I-IV  explosives  shipments  moving  via  track  or  train  within  CONUS. 
DTTS  receives  location  reports  every  two  hours  from  trucks  and  trains  using  commercial 
satellite-based  tracking  systems.  An  interface  to  GTN  provides  movement  and  shipment 
data. 

Enhanced  Logistics  Intra-Theatre  Support  Tool  (El  1ST) 

ELIST  is  a  CONUS  and  theater  transportation  feasibility  planning  and  modeling 
system  for  deployments  analysis  in  CONUS  and  in  an  overseas  theater  of  operation.  The 
mission  of  ELIST  is  to  provide  DOD’s  transportation  planners  with  a  planning  and 
analysis  tool  that  evaluates  if  major  deployments,  reception,  staging,  onward  movement, 
and  integration  (RSOI)  are  supportable  by  the  theater’s  transportation  assets  and 
infrastructure. 

Financial  Air  Clearance  Transportation  System  (TACTS') 

FACTS  consolidates  all  Service/Agency  Air  Clearance  Authority  and 
transportation  financial  management  systems'  functionality  into  a  single,  automated  DOD 
air  clearance  authority  and  financial  management  system. 

Global  Air  Transportation  Execution  System  (GATES') 

GATES  automates  support  for  receipt,  movement  and  billing  of  cargo  and 
passengers.  GATES  replaces  AMC's  command  and  control  transportation  applications 
currently  residing  on  a  mainframe,  which  include  the  Headquarters  On-line  System  for 
Transportation  (HOST),  the  Passenger  Reservation  and  Manifest  System  (PRAMS)  and 
the  Consolidated  Aerial  Port  System,  Second  Generation  (CAPS  II).  GATES  will  provide 
enhanced  capability  through  a  graphical  user  interface  and  increased  architecture,  which 
will  improve  communications  from  the  aerial  ports. 

Global  Decision  Support  System  (GDSSt 
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GDSS,  AMC’s  primary  C2  system,  is  the  source  of  planned  and  actual  itineraries, 
and  scheduled  ULN  allocations  for  all  AMC  carriers  and  tankers.  GDSS  provides  GTN 
with  real  time  updates  as  information  changes.  GDSS  provides  data  concerning  airlift 
mission  schedules,  actual  departures  and  arrivals  of  aircraft,  and  summary  information  on 
what  the  aircraft  (AMC  organic  or  commercial)  is  carrying,  to  include  OPLAN  ULNs, 
short  tons  of  cargo,  and  number  of  passengers  being  transported.  Consolidated  Air 
Mobility  Planning  System  (CAMPS),  the  AMC  system  used  to  schedule  airlift  missions, 
including  the  planned  cargo  allocation,  provides  schedule/allocation  data  via  GDSS. 
GDSS  sends  USMTF  formatted  messages  to  GTN. 

Groups  Operational  Passenger  (GOP AX)  System 

The  GOP  AX  system  is  MTMC’s  automated  support  for  movement  of  DoD  groups 
of  21  or  more  passengers  on  air,  bus,  or  rail  carriers  within  CONUS.  The  GOP  AX  system 
receives  requests  for  service  from  installations  via  Transportation  Coordinator’s 
Automated  Information  for  Movements  Systems  (TCAIMS),  telephone,  mail,  and  direct 
access  to  GOPAX.  Routing  instructions  are  sent  to  the  carrier  and  to  the  ITO/customer. 
GOPAX  provides  GTN  with  group  movement  data.  GOPAX  provides  GTN  bus  carrier 
information  pertaining  to  offer  confirmation,  requests,  and  passenger  names. 

Global  Transportation  Network  (GTN) 

GTN  will  provide  the  necessary  automated  support  tools  and  have  the  interactive 
ability  through  state-of-the-art  technology  to  manipulate  transportation  requirements  for 
the  DTS.  GTN  will  provide  customer  information  to  lift  providers  so  they  can 
proactively  support  the  stated  needs  of  DTS  customers. 

Integrated  Booking  System  (IBS) 

IBS  is  the  first  automated  system  to  standardize  cargo  booking  procedures  for  unit 
and  non-unit  CONUS  to  OCONUS  ocean-eligible  cargo.  IBS  will  receive  cargo  offerings 
from  the  shipper,  recommend  the  cost  favorable  carrier  and  appropriate  Sealift  Port  of 
Embarkation  (SPOE)  and  pass  the  offering  to  the  selected  carrier.  IBS  then  passes 
booking  strategy,  based  on  MSC  contracts/agreements,  to  the  port  for  booking. 
Additionally,  it  schedules  unit  arrivals  at  ports  and  issues  port  calls  to  units. 

Integrated  Command.  Control,  and  Communication  (1C31  System 

IC3  is  MSC’s  system  for  planning,  monitoring,  and  controlling  the  movement  of 
ships  owned  and  chartered  by  MSC.  IC3  will  integrate  Headquarters  Locator  Module 
(HELM),  MSC  Ship  Register  (P504),  Sealift  Strategic  Analysis  System  (SEASTRAT), 
Operations  Support  System  (OSS),  and  Bulk  Petroleum,  Oil  and  Lubricants  (POL),  all  of 
which  are  existing  C2,  transportation,  and  planning  systems.  IC3  interface  will  provide 
GTN  with  ship  schedules,  ship  position  data,  and  ship  port  information. 

Integrated  Computerized  Deployment  System  (ICODES) 

ICODES  supports  vessel-loading  requirements  for  all  Services  and  provides  the 
opportunity  to  develop  and  evaluate  alternative  solutions  by  predicting  problems  and 
preventing  their  occurrence. 
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Joint  Air  Logistics  Information  System  CJAT  JS) 

JALIS  assists  USTRANSCOM  with  schedule  coordination  for  operational  support 
aircraft  from  all  Services.  It  provides  schedules,  itineraries,  and  information  for  OSA 
aircraft  to  GTN. 

Mobilization  Control  (MOBCONY 

MOBCON  is  a  DOD  mobility  system  resource  that  supports  surface  road 
movements  within  CONUS.  The  system  links  an  automated  router  and  scheduler  to  a 
national  highway  database  to  manage  conflicts  in  military  wheeled  vehicle  movements 
and  facilities  permitting  of  over-dimensional  loads. 

Transportation  Coordinator’s- Automated  Information  for  Movements  System  II  fTC- 
AIMS  ID 

TC-AIMS II  consolidates  the  management  of  the  installation-level  transportation 
functions  of  unit  movement;  load  planning,  and  ITO/TMO  operations.  TC-AIMS  II 
becomes  the  standard  installation-level  unit  deployment  and  sustainment  system  for  all 
Services.  The  functionality  contained  in  the  cargo  and  passenger  movement  portions  of 
the  ITO/TMO  segment  of  TC-AIMS  H  are  the  core  of  the  application.  While  the  planning 
of  unit  movements  has  several  unique  aspects,  the  execution  of  unit  movement  operations 
is  largely  a  specialized  case  of  personnel  and  cargo  movement.  TC-AIMS  II  must  have 
the  capability  to  create  container-content  relationship  records  for  Exercise  cargo  before 
interface  with  WPS  and  IBS.  TC-AIMS  II  will  use  the  same  core  of  functionality  to 
support  routine  ITO/TMO  operations  and  unit  movement  execution. 

Transportation  Operational  Personal  Property  System  (TOPS') 

TOPS  is  an  OSD  chartered  joint  service  project  to  automate  and  standardize 
personal  property  movement,  storage,  and  management  functions  at  DOD/Coast  Guard 
Personal  Property  Shipping  and  Processing  Offices  worldwide. 

TRANSCOM  Regulating  and  Command  and  Control  Evacuation  System  (TRAC2ESY 
TRAC2ES  is  the  DoD  medical  regulating  and  aero  medical  evacuation  patient 
movement  system.  TRAC2ES  merges  medical  regulating  and  aero  medical  evacuation 
flight  planning  into  a  single  comprehensive  system  to  support  the  cost  effective 
transportation  of  DoD  patients  in  peace  and  war.  TRAC2ES  will  provide  GTN  1TV  of 
patients,  patient  attendants,  and  aero  medical  evacuation  crews  and  equipment,  via 
planned  and  actual  information  for  medical  evacuation  missions  manifested  in 
TRAC2ES.  GTN  will  provide  TRAC2ES  with  visibility  of  inter-  and  intra-  theater  lift 
assets  and  movements  of  lift  capable  of  being  used  for  medical  evacuation. 

Worldwide  Port  System  (WPS-) 

WPS  is  the  MTMC  worldwide-unclassified  system  for  managing  export  and 
import  of  DOD  cargo  at  water  ports.  It  provides  detailed  data  concerning  items  of  cargo 
arriving,  departing,  and  on-hand  at  water  ports.  WPS  records  cargo  data  for  surface 
movements  at  MTMC  area  commands;  receipt,  staging,  and  loading  cargo  at  ports;  and 
generates  the  ship  manifest/booking  upon  completion  of  vessel  loading. 
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Appendix  B 


LEGACY  SYSTEM  TERMINATION 


MIGRATION  SYSTEM 

ORIGINAL 

ACTUAL 

PROJECTED 

LEGACY  SYTEM(S) 

TERMINATION 

TERMINATION 

TERMINATION 

DATE 

DATE 

DATE 

AALPS 

CALM 

Mar-97 

TBD 

ACAS  1 

AMS 

D(F)RIF 

Nov-95 

Aug-95 

JCCOS 

Nov-95 

Jun-96 

C2IPS 

WINGS 

Jul-95 

Jul-95 

TAMS 

Dec-97 

Sep-96 

CAASS(AMC) 

TBD 

Sep-02 

EARLO 

w^Esam 

CAMPS 

AMS(AMC)  INTO  CMARPS 

Nov-95 

Nov-95 

ADANS 

Sep-98 

Feb-01 

ATS  (HORSEBLANKET) 

Jun-94 

Jun-94 

CMARPS 

Feb-01 

CanTRACS  ! 

CFM 

TRAMS 

Mar-97 

Sep-97 

FINS 

Jun-95 

Jun-95 

FL&D 

Jun-95 

Jun-95 

GOBILS 

Jan-97 

Jan-97 

NTOATMS 

Sep-95 

Sep-95 

DSOATS 

TBD 

Mar-98 

DTTS  1 

ELIST 

STADSS 

Mar-97 

Mar-97 

FACTS 

NATDS 

Mar-97 

Oct-97 

AACA  (Army) 

Jan-98 

Aug-00 

TRANSBAL 

Oct-98 

Dec-96 

ETADS 

Feb-99 

Jun-00  ! 

TFM 

Jan-99 

Jun-00 

MCACA 

Jan-99 

Mar-00  [ 

GATES 

FSS 

Sep-96 

Sep-96 

PRAMS 

Nov-97 

Nov-97 

ITRAM 

TBD 

TBD 

Comm  Gateway 

Nov-97 

Nov-99 

HOST-CRQS 

Nov-97 

Nov-97 

HOST-CONVERTER 

Feb-95 

Nov-97 

HOST-MACA 

Nov-97 

Nov-97 
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MIGRATION  SYSTEM 
LEGACY  SYTEM(S) 

GATES  (cont.) 
HOST-OVER/SHORT 
HOST-REQUEST 
HOST-TRAIS 
HOST-UPDATE 
RCAPS-CARGO 
RCAPS-PASSENGER 
CAPS  II APACCS 
CAPS  II  CARGO 
CAPS-ADAM  III 
CAPS  II SPRACS 
CAPS-PACS 


S 

GOPAX  ' 


GTN 

AMP 

JFAST 

STRADS 

SEASTRAT 

“iBS  “ 

ASPUR 
TACOS 
CDOP 
SRFS 
METSII 


IC3 
B 
V 
P504 
(CODES 
CODES 
CAEMS 
"jALiS 

NALIS  (CONUS) 

NALIS  (OCONUS) 

SIMS 

OASIS 

CAASS  Army  (CONUS) 
CAASS  Army  (OCONUS 
MOBCON 


TC-AIMS  II 
ATCCS 
CFM-FM 


ORIGINAL  ACTUAL  PROJECTED 

TERMINATION  TERMINATION  TERMINATION 
DATE _ DATE  DATE 


Nov-97 

Nov-97 

Nov-97 

Nov-97 

Nov-98 

Nov-98 

Nov-98 

Nov-98 

Dec-94 

Nov-98 

Dec-94 


Dec-94 


5 


Mar-96 


6 


Mar-97 


Jul-96 

Nov-96 

Nov-96 

Jan-98 

Nov-96 


Sep-97 

Dec-97 

Jul-95 

Jul-95 

Jun-96 

Oct-96 

Sep-96 

Sep-96 


Sep-00 

TBD 


Nov-97 

Nov-97 

Nov-97 

Nov-97 


Aug-99 
Aug-99 
Dec-94 
Aug-99 
ec-9 


Oct-97 


Jan-99 


Aug-96 

Oct-97 

Oct-97 

Oct-97 

Jan-99 


Nov-99 

Nov-99 


Sep-97 

Mar-99 

‘  Sep-97 

Oct-99 

Sep-98 


Oct-95 

Jul-99 

Oct-96 

Oct-96 

Apr-97 

Feb-99 


Sep-97 


Mar-01 


MIGRATION  SYSTEM 

ORIGINAL 

ACTUAL 

PROJECTED 

LEGACY  SYTEM(S) 

TERMINATION 

TERMINATION 

TERMINATION 

DATE 

DATE 

DATE 

TC-AIMS  II  (cont.) 

CMOS 

Sep-00 

TBD 

TMS-Freight* 

Sep-00 

Jul-98 

DAMMS-R 

TBD 

TBD 

DeMS 

Sep-00 

Sep-98 

MDSS  II 

Sep-00 

TBD 

TC-ACCIS 

Sep-00 

TBD 

TC-AIMS  (MC) 

TBD 

TOPS 

WHIST  | 

Mar-98 

Mar-98 

TRAC2ES 

APES 

Dec-00 

Dec-00 

DMRIS 

Dec-00 

Dec-00 

WPS 

DASPS-E 

Jul-95 

Jul-95 

TSM 

Dec-95 

Dec-95 

TERMS/TOLS 

Dec-95 

Dec-95 

MED-P 

Dec-96 

Jun-96 

*  NOTE:  Though  TMS-Freight  has  been  terminated,  one  site,  Camp  Lejune  still  uses  TMS-Freight 
for  RR  shipments. 
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